date:20090826

On Wednesday 22 July 2009 17:13:24 Niklaus Giger wrote:
 see http://www.jedec.org/download/search/jep106Z.pdf
 Add some second source legacy flash chips 256x8.

 Signed-off-by: Niklaus Giger niklaus.gi...@member.fsf.org

Applied to cfi-flash/next. Thanks.

Cheers,
Stefan

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

Re: [U-Boot] [PATCH v2] ppc4xx: Rename compactcenter to intip

Hi Dirk,

On Friday 21 August 2009 10:13:21 Dirk Eibach wrote:
 Signed-off-by: Dirk Eibach eib...@gdsys.de
 ---
 Changes since v1:
 - also changed config name

  Makefile|   16 
  include/configs/compactcenter.h |6 +++---
  2 files changed, 11 insertions(+), 11 deletions(-)

I just noticed that when changing the config name, you also need to change 
this in MAKEALL and MAINTAINERS. And thinking further about it, you are now 
removing the target name compactcenter, but you keep the files 
compactcenter.h and the board directory board/gdsys/compactcenter. This 
seems inconsistent to me.

Cheers,
Stefan

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

[U-Boot] Please pull u-boot-cfi-flash/next

The following changes since commit d3870bd2d832ea2048b7cb2bbb9d642585b137cf:
  Wolfgang Denk (1):
Merge branch 'next' of git://git.denx.de/u-boot-net into next

are available in the git repository at:

  git://www.denx.de/git/u-boot-cfi-flash.git next

Niklaus Giger (1):
  Support up to 7 banks for ids as specified in JEDEC JEP106Z

 drivers/mtd/cfi_flash.c   |   15 +-
 drivers/mtd/jedec_flash.c |   67 
+
 include/flash.h   |   10 ++-
 3 files changed, 89 insertions(+), 3 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Phy lib again

2009-08-26 Thread Michal Simek

Hi Ben,

Ben Warren wrote:
 Hi Michal,
 
 Michal Simek wrote:
 Hi Stefan,

 Stefan Roese wrote:
   
 Hi Michal,

 On Tuesday 25 August 2009 09:02:14 Michal Simek wrote:
 
 I saw you have phy lib in your branch. What is the current state?
 Are there any problems? When do you want to add to mainline?
   
 IIRC, Jean-Christophe is also working on a PHY lib implementation (port 
 from 
 the Linux version).

 Jean-Christophe, what's the current status of this work? I suggest you 
 start 
 sending ideas/patches for discussion soon, perhaps as RFC in the first 
 stage.
 
 Ben has it at 
 http://git.denx.de/?p=u-boot/u-boot-net.git;a=shortlog;h=refs/heads/phylib

   
 A while ago I started porting the Linux PHY library to U-boot but got 
 distracted.  This branch contains the incomplete, untested work.  I 
 suspect JC is further along, so let's see what he comes up with.  This 
 is a complicated thing that requires a well-thought-out design, so I 
 expect there will be much iteration.

Yes, I expect a lot of testing too.

Michal

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

-- 
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Custom PPC440GX board: Unsupported relocation error

2009-08-26 Thread Wouter Eckhardt

Hi all.

I've been busy getting a custom PPC440GX board to boot U-Boot. I started
with a U-Boot (version 1.3.2) based on the ALPR board and the ELDK 4.0
toolchain.

I got all that working and now I trying to move up to a newer version of
U-Boot and a newer toolchain (specifically: U-Boot 2009.03 and ELDK
4.2). After some twiddling of defines in my config file I got following
compiler error:

make[1]: Entering directory
`/data/projects/p3x440/we/u-boot-latest/board/prodrive/p3x440'
ppc_4xx-gcc -g  -Os   -fPIC -ffixed-r14 -meabi -fno-strict-aliasing
-D__KERNEL__ -DTEXT_BASE=0xFFFC
-I/data/projects/p3x440/we/u-boot-latest/include -fno-builtin
-ffreestanding -nostdinc -isystem
/data/tools/eldk-4.2/usr/bin/../lib/gcc/powerpc-linux/4.2.2/include
-pipe  -DCONFIG_PPC -D__powerpc__ -DCONFIG_4xx -ffixed-r2 -mstring
-msoft-float -Wa,-m440 -mcpu=440 -DCONFIG_440=1 -Wall
-Wstrict-prototypes -fno-stack-protector -c -o p3x440.o p3x440.c
p3x440.c: In function 'last_stage_init':
p3x440.c:88: warning: unused variable 'reg'
{standard input}: Assembler messages:
{standard input}:130: Error: unsupported relocation against uicb0sr
{standard input}:135: Error: unsupported relocation against uicb0er
{standard input}:137: Error: unsupported relocation against uicb0cr
{standard input}:142: Error: unsupported relocation against uicb0pr
{standard input}:147: Error: unsupported relocation against uicb0tr
{standard input}:152: Error: unsupported relocation against uicb0vr
make[1]: *** [p3x440.o] Error 1
make[1]: Leaving directory
`/data/projects/p3x440/we/u-boot-latest/board/prodrive/p3x440'
make: *** [board/prodrive/p3x440/libp3x440.a] Error 2

The offending piece of code is this:
int last_stage_init(void)
{
unsigned short reg;

/*
 * Configure LED's of both Marvell 88E PHY's
 *
 * This has to be done after the 4xx ethernet driver is loaded,
 * so last_stage_init() is the right place.
 */
/* TODO: WE: Fix this. */
/*
miiphy_read(ppc_4xx_eth0, CONFIG_PHY_ADDR, 0x18, reg);
reg |= 0x0001;
miiphy_write(ppc_4xx_eth0, CONFIG_PHY_ADDR, 0x18, reg);
miiphy_read(ppc_4xx_eth1, CONFIG_PHY1_ADDR, 0x18, reg);
reg |= 0x0001;
miiphy_write(ppc_4xx_eth1, CONFIG_PHY1_ADDR, 0x18, reg);
*/
return 0;
}

I'm not really sure what went wrong here. Google tells me that this is
usually related to incorrect assembler sequences. Am I missing some
compiler settings?

Thanks in advance!

Met vriendelijke groet,
Kind regards,
Wouter Eckhardt
Engineer
wouter.eckha...@prodrive.nl
tel. +31 40 2676187
Prodrive B.V.
Postbus 28030
5602 JA Eindhoven
Ekkersrijt 5025
5692 EB Son
The Netherlands
tel. +31 40 2676200
fax: +31 40 2676201
www.prodrive.nl


Disclaimer: The information contained in this email, including any attachments 
is 
confidential and is for the sole use of the intended recipient(s). Any 
unauthorized 
review, use, disclosure or distribution is prohibited. If you are not the 
intended 
recipient, please notify the sender immediately by replying to this message and 
destroy all copies of this message and any attachments.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Xilinx LL temac update

2009-08-26 Thread Michal Simek

Hi Ben,
Ben Warren wrote:
 Hi Michal,
 
 mon...@monstr.eu wrote:
 Hi Ben,

 I updated LL-temac driver - all fixes are there.
 Ad to your point Microblaze uses only one ethernet core. It is possible
 to use a lot of IPs but I don't have board like this to test it that's
 why I don't want change it.
   
 If it's possible, somebody will do it.  You don't need to have a board
 with more than one to test that it works, just create the data
 structures to encapsulate data that's specific to each instance, such as
 base address etc.  Look at the new CS8900 driver or SMC911X for examples
 of how to do this

If someone do it, then have to change that driver. I understand your opinion
but I don't need it now and it is paid IP core. It need more changes.
There is necessary change FIFO mode and phy handling + more changes in BSP
which generate parameters from HW design. It is necessary to do more complex 
changes.
I'll do that changes when phy lib is ready.

If you can, please add it to your net tree.

Thanks,
Michal




 If you find any other problem please let me know. If is OK - I'll create
 net branch with these changes (LL_TEMAC/Emaclite + removing old Emac
 driver)

   
 You won't need to do that.  I'll put it  in the main net tree.
 Thanks,
 Michal


   
 regards,
 Ben


-- 
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] why the u-boot have no upload command?or there is another way to upload data to host?

2009-08-26 Thread IaMaPlAyEr

hi all:


I do like to ask a question, why u-boot have no upload command?
image such a scene:
 you have two board, and develop with one, but to some unknow reason, the
board cannot boot.
maybe it is the hardware problem, you want to upload all the data---a bin
file, and download it to
another board.

maybe tftp should the upload function? or there is another way to upload
data to host?

thanks for reading!

-- 
--
Sincerely,

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

[U-Boot] [PATCH 1/2] drivers/mmc/atmel_mci.c: port to the new CONFIG_GENERIC_MMC API

2009-08-26 Thread Albin Tonnerre

This patch updates (well, pretty much rewrites, actually) the atmel_mci driver
so that it can be used with the new mmc API.
Currently, the driver only supports what the previous driver supported, that
is:
 - assumes that the MMC slot was configured in the cpu/board code, no
   slot-switching
 - doesn't support writing, only reading
Support for these features will come in a later patch.

Signed-off-by: Albin Tonnerre albin.tonne...@free-electrons.com
---
 drivers/mmc/atmel_mci.c |  604 +++
 1 files changed, 240 insertions(+), 364 deletions(-)

diff --git a/drivers/mmc/atmel_mci.c b/drivers/mmc/atmel_mci.c
index 3946ffe..b07deba 100644
--- a/drivers/mmc/atmel_mci.c
+++ b/drivers/mmc/atmel_mci.c
@@ -1,6 +1,9 @@
 /*
  * Copyright (C) 2004-2006 Atmel Corporation
  *
+ * Copyright (C) 2009
+ * Albin Tonnerre, Free-Electrons albin.tonne...@free-electrons.com
+ *
  * See file CREDITS for list of people who contributed to this
  * project.
  *
@@ -38,40 +41,43 @@
 #define pr_debug(...) do { } while(0)
 #endif
 
-#ifndef CONFIG_SYS_MMC_CLK_OD
-#define CONFIG_SYS_MMC_CLK_OD  15
-#endif
-
-#ifndef CONFIG_SYS_MMC_CLK_PP
-#define CONFIG_SYS_MMC_CLK_PP  500
-#endif
-
-#ifndef CONFIG_SYS_MMC_OP_COND
-#define CONFIG_SYS_MMC_OP_COND 0x0010
-#endif
-
-#define MMC_DEFAULT_BLKLEN 512
-#define MMC_DEFAULT_RCA1
+#define RESP_NO_CRC1
+#define RESP_48BITSMMCI_BF(RSPTYP, 1)
+#define RESP_136BITS   MMCI_BF(RSPTYP, 2)
+#define RESP_48BITS_NOCRC  (RESP_48BITS | RESP_NO_CRC)
+#define NIDMMCI_BF(MAXLAT, 0)
+#define NCRMMCI_BF(MAXLAT, 1)
+#define TRCMD_STARTMMCI_BF(TRCMD, 1)
+#define TRCMD_STOP MMCI_BF(TRCMD, 2)
+#define TRDIR_READ MMCI_BF(TRDIR, 1)
+#define TRTYP_BLOCKMMCI_BF(TRTYP, 0)
+
+#define ERROR_FLAGS(MMCI_BIT(DCRCE)\
+| MMCI_BIT(RDIRE)  \
+| MMCI_BIT(RENDE)  \
+| MMCI_BIT(RINDE)  \
+| MMCI_BIT(RTOE))
 
-static unsigned int mmc_rca;
-static int mmc_card_is_sd;
-static block_dev_desc_t mmc_blkdev;
+struct atmel_mci_host {
+   struct mmc  *mmc;
+   struct mmc_cmd  *cmd;
+   struct mmc_data *data;
+   u32 dtor;
+};
 
-block_dev_desc_t *mmc_get_dev(int dev)
-{
-   return mmc_blkdev;
-}
+static struct atmel_mci_host atmel_mci_host;
+static struct atmel_mci_host *host = atmel_mci_host;
 
-static void mci_set_mode(unsigned long hz, unsigned long blklen)
+static void atmel_mci_set_clk_rate(unsigned long hz)
 {
unsigned long bus_hz;
unsigned long clkdiv;
+   u32 mr;
 
bus_hz = get_mci_clk_rate();
clkdiv = (bus_hz / hz) / 2 - 1;
 
-   pr_debug(mmc: setting clock %lu Hz, block size %lu\n,
-hz, blklen);
+   pr_debug(mmc: setting clock %lu Hz\n, hz);
 
if (clkdiv  ~255UL) {
clkdiv = 255;
@@ -79,34 +85,22 @@ static void mci_set_mode(unsigned long hz, unsigned long 
blklen)
hz);
}
 
-   blklen = 0xfffc;
-   mmci_writel(MR, (MMCI_BF(CLKDIV, clkdiv)
-| MMCI_BF(BLKLEN, blklen)
-| MMCI_BIT(RDPROOF)
-| MMCI_BIT(WRPROOF)));
+   mr = mmci_readl(MR);
+   mmci_writel(MR, MMCI_BFINS(CLKDIV, clkdiv, mr));
 }
 
-#define RESP_NO_CRC1
-#define R1 MMCI_BF(RSPTYP, 1)
-#define R2 MMCI_BF(RSPTYP, 2)
-#define R3 (R1 | RESP_NO_CRC)
-#define R6 R1
-#define NIDMMCI_BF(MAXLAT, 0)
-#define NCRMMCI_BF(MAXLAT, 1)
-#define TRCMD_STARTMMCI_BF(TRCMD, 1)
-#define TRDIR_READ MMCI_BF(TRDIR, 1)
-#define TRTYP_BLOCKMMCI_BF(TRTYP, 0)
-#define INIT_CMD   MMCI_BF(SPCMD, 1)
-#define OPEN_DRAIN MMCI_BF(OPDCMD, 1)
-
-#define ERROR_FLAGS(MMCI_BIT(DTOE) \
-| MMCI_BIT(RDIRE)  \
-| MMCI_BIT(RENDE)  \
-| MMCI_BIT(RINDE)  \
-| MMCI_BIT(RTOE))
+
+static void atmel_mci_set_blklen(unsigned long blklen)
+{
+   u32 mr;
+
+   blklen = 0xfffc;
+   mr = mmci_readl(MR);
+   mmci_writel(MR, MMCI_BFINS(BLKLEN, blklen, mr));
+}
 
 static int
-mmc_cmd(unsigned long cmd, unsigned long arg,
+atmel_mci_mmc_cmd(unsigned long cmd, unsigned long arg,
void *resp, unsigned long flags)
 {
unsigned long *response = resp;
@@ -140,7 +134,7 @@ mmc_cmd(unsigned long cmd, unsigned long arg,
if (status  error_flags) {
printf(mmc: command %lu failed (status: 0x%08x)\n,
   cmd, status);
-   return -EIO;
+   return status;
}
 
if (response_words)

[U-Boot] [PATCH 2/2] AVR32: update to use CONFIG_GENERIC_MMC

2009-08-26 Thread Albin Tonnerre

With the patch updating the atmel_mci driver, some updates are necessary on
AVR32 to make the MMC support working. This patch defines CONFIG_GENERIC_MMC in
the affected boards config and defines the function cpu_mmc_init.

Signed-off-by: Albin Tonnerre albin.tonne...@free-electrons.com
---
As I don't own any AVR32 hardware, I would really appreciate if some extensive
testing was performed on this platform to avoid regressions

 cpu/at32ap/cpu.c|7 +++
 include/configs/atngw100.h  |1 +
 include/configs/atstk1002.h |1 +
 include/configs/atstk1003.h |1 +
 include/configs/atstk1004.h |1 +
 include/configs/atstk1006.h |1 +
 include/configs/favr-32-ezkit.h |1 +
 include/configs/hammerhead.h|1 +
 include/configs/mimc200.h   |1 +
 9 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/cpu/at32ap/cpu.c b/cpu/at32ap/cpu.c
index 904bfb2..71771bc 100644
--- a/cpu/at32ap/cpu.c
+++ b/cpu/at32ap/cpu.c
@@ -87,3 +87,10 @@ int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char 
*argv[])
 
return -1;
 }
+
+#ifdef CONFIG_ATMEL_MCI
+int cpu_mmc_init(bd_t *bis)
+{
+   atmel_mci_init(bis);
+}
+#endif
diff --git a/include/configs/atngw100.h b/include/configs/atngw100.h
index 4ed5514..580f964 100644
--- a/include/configs/atngw100.h
+++ b/include/configs/atngw100.h
@@ -128,6 +128,7 @@
 #define CONFIG_SYS_NR_PIOS 5
 #define CONFIG_SYS_HSDRAMC 1
 #define CONFIG_MMC 1
+#define CONFIG_GENERIC_MMC 1
 #define CONFIG_ATMEL_MCI   1
 #define CONFIG_ATMEL_SPI   1
 
diff --git a/include/configs/atstk1002.h b/include/configs/atstk1002.h
index b258f2d..c83c30d 100644
--- a/include/configs/atstk1002.h
+++ b/include/configs/atstk1002.h
@@ -153,6 +153,7 @@
 #define CONFIG_SYS_NR_PIOS 5
 #define CONFIG_SYS_HSDRAMC 1
 #define CONFIG_MMC 1
+#define CONFIG_GENERIC_MMC 1
 #define CONFIG_ATMEL_MCI   1
 
 #define CONFIG_SYS_DCACHE_LINESZ   32
diff --git a/include/configs/atstk1003.h b/include/configs/atstk1003.h
index 2ef2552..9077c5c 100644
--- a/include/configs/atstk1003.h
+++ b/include/configs/atstk1003.h
@@ -136,6 +136,7 @@
 #define CONFIG_PORTMUX_PIO 1
 #define CONFIG_SYS_HSDRAMC 1
 #define CONFIG_MMC 1
+#define CONFIG_GENERIC_MMC 1
 #define CONFIG_ATMEL_MCI   1
 
 #define CONFIG_SYS_DCACHE_LINESZ   32
diff --git a/include/configs/atstk1004.h b/include/configs/atstk1004.h
index 195be82..a06f2bf 100644
--- a/include/configs/atstk1004.h
+++ b/include/configs/atstk1004.h
@@ -136,6 +136,7 @@
 #define CONFIG_PORTMUX_PIO 1
 #define CONFIG_SYS_HSDRAMC 1
 #define CONFIG_MMC 1
+#define CONFIG_GENERIC_MMC 1
 #define CONFIG_ATMEL_MCI   1
 
 #define CONFIG_SYS_DCACHE_LINESZ   32
diff --git a/include/configs/atstk1006.h b/include/configs/atstk1006.h
index f93118e..ed82e66 100644
--- a/include/configs/atstk1006.h
+++ b/include/configs/atstk1006.h
@@ -153,6 +153,7 @@
 #define CONFIG_SYS_NR_PIOS 5
 #define CONFIG_SYS_HSDRAMC 1
 #define CONFIG_MMC 1
+#define CONFIG_GENERIC_MMC 1
 #define CONFIG_ATMEL_MCI   1
 
 #define CONFIG_SYS_DCACHE_LINESZ   32
diff --git a/include/configs/favr-32-ezkit.h b/include/configs/favr-32-ezkit.h
index 739ff0d..1fc38f7 100644
--- a/include/configs/favr-32-ezkit.h
+++ b/include/configs/favr-32-ezkit.h
@@ -150,6 +150,7 @@
 #define CONFIG_SYS_NR_PIOS 5
 #define CONFIG_SYS_HSDRAMC 1
 #define CONFIG_MMC 1
+#define CONFIG_GENERIC_MMC 1
 #define CONFIG_ATMEL_MCI   1
 
 #define CONFIG_SYS_DCACHE_LINESZ   32
diff --git a/include/configs/hammerhead.h b/include/configs/hammerhead.h
index 0c70af5..e4b3e20 100644
--- a/include/configs/hammerhead.h
+++ b/include/configs/hammerhead.h
@@ -121,6 +121,7 @@
 #define CONFIG_SYS_NR_PIOS 5
 #define CONFIG_SYS_HSDRAMC 1
 #define CONFIG_MMC 1
+#define CONFIG_GENERIC_MMC 1
 #define CONFIG_ATMEL_MCI   1
 
 #define CONFIG_SYS_DCACHE_LINESZ   32
diff --git a/include/configs/mimc200.h b/include/configs/mimc200.h
index 8f71664..26f6cf3 100644
--- a/include/configs/mimc200.h
+++ b/include/configs/mimc200.h
@@ -127,6 +127,7 @@
 #define CONFIG_SYS_NR_PIOS 5
 #define CONFIG_SYS_HSDRAMC 1
 #define CONFIG_MMC 1
+#define CONFIG_GENERIC_MMC 1
 #define CONFIG_ATMEL_MCI   1
 
 #if defined(CONFIG_LCD)
-- 
1.6.0.4

___
U-Boot mailing list

[U-Boot] Continuos reboot in u-boot 1.3.4

2009-08-26 Thread Virupax . SS

Hi 

I am using u-boot 1.3.4 ( got from atmel) on AT91SAM9G20 , If enable the 
ethernet related code in the u-boot ( drivers etc) the board starts 
resetting again and again continuously without giving any error message. 
Please somebody tell me what type of mistakes ( coding errors ) make the 
board to reset in u-boot. Or it is because of writing some wrong values in 
the controller resisters. 
Thanks 


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

Re: [U-Boot] [RESEND][PATCH 3/6]POSEIDON Board Support

2009-08-26 Thread Vivek

Hi Wolfgang

- Original Message - 
From: Wolfgang Denk w...@denx.de
To: Vivek v.da...@samsung.com
Cc: Scott Wood scottw...@freescale.com; u-boot@lists.denx.de
Sent: Friday, July 31, 2009 12:34 AM
Subject: Re: [U-Boot] [RESEND][PATCH 3/6]POSEIDON Board Support


 Dear Vivek,

 In message b887d7d8b9d94a0f80640358260fa...@sisodomain.com you wrote:
 Removed code referring Legacy NAND and did some code cleanup.

 Such version comments should go below the --- line, not above.

OK...
 Signed-off-by: Vivek Dalal v.da...@samsung.com
 ---

 Consider using git-format-patch to create the patches.

OK, I will use it.

 MAINAINERS entry is missing.

 MAKEALL entry is missing.

 Top level Makefile entry is missing.

 diff --git a/board/poseidon/Makefile b/board/poseidon/Makefile
 index e69de29..edbc696 100644
 --- a/board/poseidon/Makefile
 +++ b/board/poseidon/Makefile
 @@ -0,0 +1,48 @@
 +#
 +# (C) Copyright 2009-2010

 Hey. PLease tell me where you got that time machine from. You're
 already living in 2010 ?

 Please fix globally.

OK..Will modify


 ...
 +include $(TOPDIR)/config.mk
 +
 +LIB = lib$(BOARD).a
 +
 +OBJS := poseidon.o mem.o sys_info.o
 +SOBJS := lowlevel_init.o load.o
 +
 +$(LIB): $(OBJS) $(SOBJS)
 + $(AR) crv $@ $^
 +
 +clean:
 + rm -f $(SOBJS) $(OBJS)
 +
 +distclean: clean
 + rm -f $(LIB) core *.bak .depend
 +
 +#
 +
 +.depend: Makefile $(SOBJS:.o=.S) $(OBJS:.o=.c)
 + $(CC) -M $(CPPFLAGS) $(SOBJS:.o=.S) $(OBJS:.o=.c)  $@
 +
 +-include .depend

 This Makefile does not support out-of-tree building. Please fix.

OK

 diff --git a/board/poseidon/config.mk b/board/poseidon/config.mk
 index e69de29..f05593c 100644
 --- a/board/poseidon/config.mk
 +++ b/board/poseidon/config.mk
 ...
 +# For use with external or internal boots.
 +TEXT_BASE = 0x83e8
 +
 +# Handy to get symbols to debug ROM version.
 +#TEXT_BASE = 0x0
 +#TEXT_BASE = 0x0800
 +#TEXT_BASE = 0x0400

 Please do not add dead code. Remove this.

OK, Will do that.

 diff --git a/board/poseidon/lowlevel_init.S b/board/poseidon/lowlevel_init.S
 index e69de29..9052f71 100644
 --- a/board/poseidon/lowlevel_init.S
 +++ b/board/poseidon/lowlevel_init.S
 ...
 + */
 +.global cpy_clk_code
 + cpy_clk_code:
 +/* Copy DPLL code into SRAM */
 +adr r0, go_to_speed /* get addr of clock setting code */
 +mov r2, #384/* r2 size to copy (div by 32 
 bytes) */
 +mov r1, r1  /* r1 - dest address (passed in) */
 +add r2, r2, r0  /* r2 - source end address */
 +next2:
 +ldmia   r0!, {r3-r10}   /* copy from source address [r0]
 */
 +stmia   r1!, {r3-r10}   /* copy to   target address [r1]
 */
 +cmp r0, r2  /* until source end address [r2]
 */
 +bne next2
 + mov pc, lr  /* back to caller */

 Here and everywhere else: indentation by TAB only, please.

Already taken care indentation but missed at some places. For checking codng 
gudilines I used checkpatch.pl script of linux. Will 
look with more care.

 +/*
 + *  go_to_speed: -Moves to bypass, -Commits clock dividers, -puts dpll at 
 speed
 + *   -executed from SRAM.
 + *  R0 = PRCM_CLKCFG_CTRL - addr of valid reg
 + *  R1 = CM_CLKEN_PLL - addr dpll ctlr reg
 + *  R2 = dpll value
 + *  R3 = CM_IDLEST_CKGEN - addr dpll lock wait
 + 
 **/

 Incorrect multiline comment style.

 + /* now prepare GPMC (flash) for new dpll speed */
 + /* flash needs to be stable when we jump back to it */

 Incorrect multiline comment style.

 + /* setup to 2x loop though code.  The first loop pre-loads the
 + * icache, the 2nd commits the prcm config, and locks the dpll
 + */

 Incorrect multiline comment style.

 Please fix globally.

Will do for all cases. ACK

 diff --git a/board/poseidon/mem.c b/board/poseidon/mem.c
 index e69de29..8f7dc65 100644
 --- a/board/poseidon/mem.c
 +++ b/board/poseidon/mem.c
 ...
 +/* Board CS Organization - Poseidon */
 +static const unsigned char chip_sel_sdp[][GPMC_MAX_CS] = {
 + /* GPMC CS Indices */
 + /* S8- 1   2   3 IDX CS0, CS1, CS2 .. CS7  */
 + /* 0 OFF OFF OFF */ {0, 0, 0, 0, 0, 0, 0, 0},
 + /* 0 OFF OFF OFF */ {0, 0, 0, 0, 0, 0, 0, 0},
 + /* 0 OFF OFF OFF */ {0, 0, 0, 0, 0, 0, 0, 0},
 + /* 0 OFF OFF OFF */ {0, 0, 0, 0, 0, 0, 0, 0},
 + /* 0 OFF OFF OFF */ {0, 0, 0, 0, 0, 0, 0, 0},
 + /* 0 OFF OFF OFF */ {0, 0, 0, 0, 0, 0, 0, 0},
 + /* 0 OFF OFF OFF */ {0, 0, 0, 0, 0, 0, 0, 0},
 + /* 7 ON  ON  ON  */
 + {PROC_ONENAND, PROC_NAND, PISMO_CS0, 0, 0, DBG_MPDB, 0, PISMO_CS1},
 +};
 +
 +

 Only one blank line here.

OK..and will take care in other cases too.

 +/* Values for each of the

Re: [U-Boot] Custom PPC440GX board: Unsupported relocation error

Dear Wouter Eckhardt,

In message 4cd35cd1f8085945b597f80eec8942130348d...@exc01.bk.prodrive.nl you 
wrote:
 
 I've been busy getting a custom PPC440GX board to boot U-Boot. I started
 with a U-Boot (version 1.3.2) based on the ALPR board and the ELDK 4.0
 toolchain.
 
 I got all that working and now I trying to move up to a newer version of
 U-Boot and a newer toolchain (specifically: U-Boot 2009.03 and ELDK
 4.2). After some twiddling of defines in my config file I got following
 compiler error:
 
...
 p3x440.c:88: warning: unused variable 'reg'
 {standard input}: Assembler messages:
 {standard input}:130: Error: unsupported relocation against uicb0sr
 {standard input}:135: Error: unsupported relocation against uicb0er
 {standard input}:137: Error: unsupported relocation against uicb0cr
 {standard input}:142: Error: unsupported relocation against uicb0pr
 {standard input}:147: Error: unsupported relocation against uicb0tr
 {standard input}:152: Error: unsupported relocation against uicb0vr
...
 The offending piece of code is this:

No, this is not the related source code. If you look at it, you will
notice that it does not include an uicb string at all.

I think You have a typo somewhere in your source. Search and replace
all uicb0 strings by uic0 and try again.

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
Love your country but never trust its government.
- from a hand-painted road sign in central Pennsylvania
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Re-distributing mkimage binary

2009-08-26 Thread Premi, Sanjeev

Hi,

Is it possible to redistribute the mkimage binary outside the u-boot package?

Best regards,
Sanjeev

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

Re: [U-Boot] Re-distributing mkimage binary

2009-08-26 Thread Kumar Gala

As long as you conform to the GPL its fine.

- k

On Aug 26, 2009, at 9:15 AM, Premi, Sanjeev wrote:

 Hi,

 Is it possible to redistribute the mkimage binary outside the u-boot  
 package?

 Best regards,
 Sanjeev

 ___
 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] Re-distributing mkimage binary

Dear Sanjeev,

In message b85a65d85d7eb246be421b3fb0fbb59301dd430...@dbde02.ent.ti.com you 
wrote:
 
 Is it possible to redistribute the mkimage binary outside the u-boot package?

Yes, of course this is possible. It's Free Software under GPL, so you
can modify and/or repackage it as you like. Just make sure to fulfill
the requirements of the GPL which still  apply,  no  matter  how  you
split it off...

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
Punishment becomes ineffective after a certain point. Men become  in-
sensitive.
-- Eneg, Patterns of Force, stardate 2534.7
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Re-distributing mkimage binary

2009-08-26 Thread Premi, Sanjeev

 -Original Message-
 From: Wolfgang Denk [mailto:w...@denx.de] 
 Sent: Wednesday, August 26, 2009 8:20 PM
 To: Premi, Sanjeev
 Cc: U-Boot Mailing List
 Subject: Re: [U-Boot] Re-distributing mkimage binary

 Dear Sanjeev,

 In message 
 b85a65d85d7eb246be421b3fb0fbb59301dd430...@dbde02.ent.ti.com
  you wrote:

  Is it possible to redistribute the mkimage binary outside 
 the u-boot package?

 Yes, of course this is possible. It's Free Software under GPL, so you
 can modify and/or repackage it as you like. Just make sure to fulfill
 the requirements of the GPL which still  apply,  no  matter  how  you
 split it off...

U-boot and Linux kernel sources are available in the same package, but
the intent was to allow linux developers to bypass the step to build
u-boot just get this binary.

Best regards,
Sanjeev

 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
 Punishment becomes ineffective after a certain point. Men become  in-
 sensitive.
   -- Eneg, Patterns of Force, stardate 2534.7

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

[U-Boot] ARM926ej, trying to serve interrupt

2009-08-26 Thread Ricardo Martínez

Hi,
 
I'm trying to printf something when one timer generates an interrupt.
 
u-boot version is 1.3.4.
 
The steps I've followed:
- #define CONFIG_USE_IRQ
- I've enabled interrupts
- I've enabled timer interrupt
- I've enabled timer
- I've checked interrupt masks
- I've checked interrupt status flags prior to timer interrupt
 
The problem is that when timer generates interrupt (reaches 0 after several
cycles), I expect default u-boot code do_irq, called from .irq: address
defined in start.S get executed. In that function is where I want to
printf anything to check it is working. But the whole system hangs. When
timer generates the interrupt, ARM9 hangs without printing anything and
normal execution is freezed.
 
printf and serial driver work perfectly because I've checked the steps above
with prinft debugguing.
 
I bet that when timer interrupts CPU, it jumps to code section not defined.
The question is... How can I program the expected behaviour? I mean
executing do_irq when the interrupt is generated.
 
Thanks in advance for your help.
Best regards,
Ricardo Martinez

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

[U-Boot] Please pull u-boot-coldfire

2009-08-26 Thread Liew Tsi Chung-R5AAHP

Hi Wolfgang,

The following changes since commit
d3870bd2d832ea2048b7cb2bbb9d642585b137cf:
  Wolfgang Denk (1):
Merge branch 'next' of git://git.denx.de/u-boot-net into next

are available in the git repository at:

  git://www.denx.de/git/u-boot-coldfire.git next

TsiChung Liew (2):
  ColdFire: Fix missing _IO_BASE which caused compile error
  ColdFire: Fix compile warning messages

 cpu/mcf5227x/cpu_init.c  |1 -
 cpu/mcf532x/cpu_init.c   |1 -
 drivers/dma/MCD_dmaApi.c |   16 ++--
 include/asm-m68k/io.h|4 
 4 files changed, 14 insertions(+), 8 deletions(-)


Thanks!

Regards,
TsiChung


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

Re: [U-Boot] Custom PPC440GX board: Unsupported relocation error

2009-08-26 Thread Wouter Eckhardt

 -Original Message-
 From: Wolfgang Denk [mailto:w...@denx.de]
 Sent: woensdag 26 augustus 2009 15:38
 To: Wouter Eckhardt
 Cc: u-boot@lists.denx.de
 Subject: Re: [U-Boot] Custom PPC440GX board: Unsupported relocation
 error

 Dear Wouter Eckhardt,

 In message
4cd35cd1f8085945b597f80eec8942130348d...@exc01.bk.prodrive.nl
 you wrote:

  I've been busy getting a custom PPC440GX board to boot U-Boot. I
started
  with a U-Boot (version 1.3.2) based on the ALPR board and the ELDK
4.0
  toolchain.

  I got all that working and now I trying to move up to a newer
version of
  U-Boot and a newer toolchain (specifically: U-Boot 2009.03 and ELDK
  4.2). After some twiddling of defines in my config file I got
following
  compiler error:

 ...
  p3x440.c:88: warning: unused variable 'reg'
  {standard input}: Assembler messages:
  {standard input}:130: Error: unsupported relocation against uicb0sr
  {standard input}:135: Error: unsupported relocation against uicb0er
  {standard input}:137: Error: unsupported relocation against uicb0cr
  {standard input}:142: Error: unsupported relocation against uicb0pr
  {standard input}:147: Error: unsupported relocation against uicb0tr
  {standard input}:152: Error: unsupported relocation against uicb0vr
 ...
  The offending piece of code is this:

 No, this is not the related source code. If you look at it, you will
 notice that it does not include an uicb string at all.

 I think You have a typo somewhere in your source. Search and replace
 all uicb0 strings by uic0 and try again.

Thanks! Fixed now. (I was a bit thrown off since these errors came after
the earlier warning.) Seems I shouldn't have blindly copied my board.c
from one U-Boot version to the other.

Kind regards,
Wouter Eckhardt.

 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
 Love your country but never trust its government.
 - from a hand-painted road sign in central Pennsylvania

Disclaimer: The information contained in this email, including any attachments 
is 
confidential and is for the sole use of the intended recipient(s). Any 
unauthorized 
review, use, disclosure or distribution is prohibited. If you are not the 
intended 
recipient, please notify the sender immediately by replying to this message and 
destroy all copies of this message and any attachments.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] ARM926ej, trying to serve interrupt

Dear =?iso-8859-1?Q?Ricardo_Mart=EDnez?=,

In message 
!!aaayajp7zgtd32xai3bhclyaeq3cgaaaeoigrx5geblkkejr+11mkvqba...@teltronic.es
 you wrote:

 I'm trying to printf something when one timer generates an interrupt.

Hm... there are certain things you can do in interrupt contect, amd
certain things you cannot do.

Remember that in standard C you can in a signal handler  only  modify
vailables  of  type  sigatomic_t  -  you  must  not  call any library
functions, you must noit call any system calls. Well, in  praxis  you
will  probably  find  tat  system  calls  are  safe to call, and most
library functions can be used as well - but nly when you  know  their
implementation  well enough to understand exactly what they are (not)
doing.

Calling a printf() [which internally may need to allocate buffers, and
thus call malloc() and a lot of other complex functions] is something
you must never do ina signal handler.

Why do you think you can get away with the same here in U-Boot? Even
in interrupt contxt, which is probably even more restricitve?

 u-boot version is 1.3.4.

Old. OLD. I mean: OLD!!!  Please update.

 The problem is that when timer generates interrupt (reaches 0 after several
 cycles), I expect default u-boot code do_irq, called from .irq: address
 defined in start.S get executed. In that function is where I want to
 printf anything to check it is working. But the whole system hangs. When
 timer generates the interrupt, ARM9 hangs without printing anything and
 normal execution is freezed.
  
 printf and serial driver work perfectly because I've checked the steps above
 with prinft debugguing.

Is there any chance that the serial driver might be using interrupts,
too, and that you run into some nested interrupt  handling  which  is
not or not correctly supported by U-Boot?


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
After a time, you may find that having is not so pleasing a thing,
after all, as wanting.  It is not logical, but it is often true.
-- Spock, Amok Time, stardate 3372.7
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 2/3] Reset interrupted i2c slaves (galaxy5200)

2009-08-26 Thread Eric Millbrandt

Hi Heiko,

On Wed, 26 Aug 2009 08:57:46 +0200, Heiko Schocher wrote
 Hello Eric,
 
 Eric Millbrandt wrote:
  Reset any i2c devices that may have been interrupted by a system reset.
  Normally this would be accomplished by clocking the line until SCL and SDA
  are released and then sending a start condtiion (From an Atmel datasheet).
  But since there is only write access to these lines on the MPC5200 we can
  only attempt to reset any slave devices by sending more start commands than
  bits the slave is attempting to transmit.
  
  Signed-off-by: Eric Millbrandt emillbra...@dekaresearch.com
  ---
  
  Changes since v1:
  - Remove non-related modifications to a different patch per Peter's 
  suggestion
 
 one common comment:
 
 Can you please use in_*/out_* accessors for accessing mpc52xx registers.

Ok.  I will do that.
  
   board/galaxy5200/galaxy5200.c |   41
+
   include/configs/galaxy5200.h  |1 +
   2 files changed, 42 insertions(+), 0 deletions(-)
  
  diff --git a/board/galaxy5200/galaxy5200.c b/board/galaxy5200/galaxy5200.c
  index 5aa9d3a..c38e7de 100644
  --- a/board/galaxy5200/galaxy5200.c
  +++ b/board/galaxy5200/galaxy5200.c
  @@ -155,6 +155,47 @@ phys_size_t initdram(int board_type)
  return dramsize + dramsize2;
   }
   
  +/*
  + * Reset any i2c devices that may have been interrupted by a system reset.
  + * Normally this would be accomplished by clocking the line until SCL and 
  SDA
  + * are released and then sending a start condtiion (From an Atmel 
  datasheet).
  + * But since there is only write access to these lines on the MPC5200 we 
  can
  + * only attempt to reset any slave devices by sending more start commands
than
  + * bits the slave is attempting to transmit.
  + */
  +int misc_init_f(void)
 
 Hmm.. why in misc_init_f? Can you move this function to the mpc52xx i2c
 driver, and add this in a manner like the send_reset() function
 in drivers/i2c/soft_i2c.c? And call this send_reset() in the
 i2c_init() from the mpc52xx i2c driver. As I don;t know, if this
 is valid for all mpc52xx boards, it should be then also per
 CONFIG_SYS_* define selectable.

The i2c registers that I used are only on the MPC5200B, not the MPC5200.  I
put the reset function under misc_init_f for that reason.  Is adding a single
cpu dependent function appropriate for the entire cpu/5xxx family branch?  If
it is then I will move the reset function to the mpc5xxx i2c driver.

Thanks

http://openwebmail.org - eem

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

Re: [U-Boot] Please pull u-boot-cfi-flash/next

Dear Stefan Roese,

In message 200908260911.36968...@denx.de you wrote:
 The following changes since commit d3870bd2d832ea2048b7cb2bbb9d642585b137cf:
   Wolfgang Denk (1):
 Merge branch 'next' of git://git.denx.de/u-boot-net into next
 
 are available in the git repository at:
 
   git://www.denx.de/git/u-boot-cfi-flash.git next
 
 Niklaus Giger (1):
   Support up to 7 banks for ids as specified in JEDEC JEP106Z
 
  drivers/mtd/cfi_flash.c   |   15 +-
  drivers/mtd/jedec_flash.c |   67 
 +
  include/flash.h   |   10 ++-
  3 files changed, 89 insertions(+), 3 deletions(-)

Applied, 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
You know, after a woman's raised a family and so on,  she  wants  to
start living her own life.   Whose life she's _been_ living, then?
  - Terry Pratchett, _Witches Abroad_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Please pull u-boot-coldfire

Dear Liew Tsi Chung-R5AAHP,

In message 
4791e710007feb4bbf83775d787f462f08d3d...@az33exm22.fsl.freescale.net you 
wrote:
 Hi Wolfgang,
 
 The following changes since commit
 d3870bd2d832ea2048b7cb2bbb9d642585b137cf:
   Wolfgang Denk (1):
 Merge branch 'next' of git://git.denx.de/u-boot-net into next
 
 are available in the git repository at:
 
   git://www.denx.de/git/u-boot-coldfire.git next
 
 TsiChung Liew (2):
   ColdFire: Fix missing _IO_BASE which caused compile error
   ColdFire: Fix compile warning messages
 
  cpu/mcf5227x/cpu_init.c  |1 -
  cpu/mcf532x/cpu_init.c   |1 -
  drivers/dma/MCD_dmaApi.c |   16 ++--
  include/asm-m68k/io.h|4 
  4 files changed, 14 insertions(+), 8 deletions(-)

Applied, 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
I realize that command does have its fascination, even under  circum-
stances such as these, but I neither enjoy the idea of command nor am
I  frightened  of  it. It simply exists, and I will do whatever logi-
cally needs to be done.
-- Spock, The Galileo Seven, stardate 2812.7
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Cleanup typo and trailing whitespace

Dear Eric Millbrandt,

In message 20090825152816.m45...@coldhaus.com you wrote:
 Cleanup typo and trailing whitespace from galaxy5200.h
 
 Signed-off-by: Eric Millbrandt emillbra...@dekaresearch.com
 ---
  include/configs/galaxy5200.h |8 
  1 files changed, 4 insertions(+), 4 deletions(-)

Applied to next, 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
KLB is an acronym for `Known Lazy Bastard', aka non-FAQ  reader,  aka
person  who  would  rather  make  someone  take their time to explain
something basic than look it up in a  FAQ.
 -- Tom Christiansen in 6aq547$mn...@csnews.cs.colorado.edu
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v4] use common code for Matrix Vision boards

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

In message 1250682092.22118.8.ca...@swa-m460 you wrote:
 clean up existing boards (mvBC-P/MPC5200 and mvBL-M7/MPC8343)
 by using common code.
 
 
 Signed-off-by: Andr=C3=A9 Schwarz andre.schw...@matrix-vision.de
 ---
 
 Wolfgang,
 this is my current diff against your latest master repository - I'm
 unable to split it anymore.
 Unfortunately the e1000 is currently not working on the mvBC-P but this
 is due to changes in drivers/net/e1000.c ... using the last released
 version is working fine. Will contact the maintainer to fix it.
 Hopefully you'll nevertheless apply this patch so that everybody using
 the boards can get up-to-date again.

Sorry for the late reply.

...
 diff --git a/board/matrix_vision/mvbc_p/mvbc_p_autoscript
 b/board/matrix_vision/mvbc_p/mvbc_p_autoscript
 index 5cee6c5..1102354 100644
 --- a/board/matrix_vision/mvbc_p/mvbc_p_autoscript
 +++ b/board/matrix_vision/mvbc_p/mvbc_p_autoscript
 @@ -5,7 +5,7 @@ setenv bootdtb bootm \${kernel_boot} \
 ${mv_initrd_addr_ram} \${mv_dtb_addr_ram}
  setenv ramkernel setenv kernel_boot \${loadaddr}
  setenv flashkernel setenv kernel_boot \${mv_kernel_addr}
  setenv cpird cp \${mv_initrd_addr} \${mv_initrd_addr_ram} \
 ${mv_initrd_length}
 -setenv bootfromflash run flashkernel cpird ramparam addcons e1000para
 bootdtb
 +setenv bootfromflash run flashkernel cpird ramparam addcons e1000para
 addprofile bootdtb



Patch is linewrapped here and elsewhere and thus cannot be applied.

Please fix and resubmit. Make sure to use git-send-email for sending.

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
Men will always be men -- no matter where they are.
-- Harry Mudd, Mudd's Women, stardate 1329.8
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] OneNAND: Remove unused read_spareram

Dear Kyungmin Park,

In message 20090721025804.ga3...@july you wrote:
 Remove unused read_spareram and add unlock_all as kernel does
 
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 ---

Applied to next, 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
PUBLIC NOTICE AS REQUIRED BY LAW:  Any Use of This  Product,  in  Any
Manner  Whatsoever,  Will  Increase  the  Amount  of  Disorder in the
Universe. Although No Liability Is Implied Herein,  the  Consumer  Is
Warned  That  This  Process Will Ultimately Lead to the Heat Death of
the Universe.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-boot][PATCH] AMCC ppc440SPe PCIe PLL lock error

Dear Stefan,

In message 89f945070907210538u2784629ev72346813b8a35...@mail.gmail.com 
Rupjyoti Sarmah wrote:
 u-boot reports a PCIE PLL lock error at boot time on Yucca
 board, and left PCIe nonfunctional. This is fixed by making u-boot
 function ppc4xx_init_pcie() to wait 300 uS after negating reset before
 the first check of PLL lock.
 
 This fix touches only one file 4xx_pcie.c
 
 Signed off by  Rupjyoti Sarmah  rsar...@amcc.com  from Applied Micro
 

I did not see any comments from you to this, nor can I see it your
repo?

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
Democracy is mob rule, but with income taxes.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Add some second source legacy flash chips 256x8

Dear Stefan,

In message 1248205624-17062-1-git-send-email-niklaus.gi...@member.fsf.org 
Niklaus Giger wrote:
 Signed-off-by: Niklaus Giger niklaus.gi...@member.fsf.org
 ---
 
 We tested some boot flashes as possible second source.
 As some had ids above 0x7f, we had to implement JEDEC JEP106Z in cfi_flash.c.
 I now that I just missed the merge window, but the patches are not urgent
 and I was away for a three week
 
  drivers/mtd/cfi_flash.c   |   16 +--
  drivers/mtd/jedec_flash.c |   67 
 +
  include/flash.h   |   10 ++-
  3 files changed, 89 insertions(+), 4 deletions(-)

Any chance to pick this up for next?

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
Ever try. Ever fail. No matter. Try again. Fail again.  Fail  better.
-- S. Beckett
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

Dear Scott,

In message 20090814070359.gd11...@game.jcrosoft.org Jean-Christophe 
PLAGNIOL-VILLARD wrote:
 On 02:32 Tue 11 Aug , Ilya Yanok wrote:
  This patch adds support for i.MX27-LITEKIT development board from
  LogicPD. This board uses i.MX27 SoC and has 2MB NOR flash, 64MB NAND
  flash, FEC ethernet controller integrated into i.MX27.
  
  Signed-off-by: Ilya Yanok ya...@emcraft.com
  ---
   MAINTAINERS |1 +
   MAKEALL |1 +
   Makefile|3 +
   board/logicpd/imx27lite/Makefile|   51 ++
   board/logicpd/imx27lite/config.mk   |1 +
   board/logicpd/imx27lite/imx27lite.c |   73 +
   board/logicpd/imx27lite/lowlevel_init.S |  170 +
   cpu/arm926ejs/mx27/generic.c|   65 
   include/asm-arm/arch-mx27/imx-regs.h|   12 ++
   include/configs/imx27lite.h |  252 
  +++
   10 files changed, 629 insertions(+), 0 deletions(-)
   create mode 100644 board/logicpd/imx27lite/Makefile
   create mode 100644 board/logicpd/imx27lite/config.mk
   create mode 100644 board/logicpd/imx27lite/imx27lite.c
   create mode 100644 board/logicpd/imx27lite/lowlevel_init.S
   create mode 100644 include/configs/imx27lite.h
 Acked-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
 
 Scott could you applied on your tree as this one need the nand patch that you
 handle

Could you please run this through your next branch and send a pullr
equest? TIA.

Acked-by: Wolfgang Denk w...@denx.de

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 father doesn't destroy his children.
-- Lt. Carolyn Palamas, Who Mourns for Adonais?,
   stardate 3468.1.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] How can I make a second serial port on a motorola 8248 Chip known to Linux.

2009-08-26 Thread AGKohler

I am using u-boot version 1.1.3, kernel, Linux(Debian) is version 2.6.12.
I searched through the kernel configuration options via menuconfig, i could
not find
anything that configures the number of serial ports. In LINUX, i tried
creating ttyS1 with
mknod -m 660 /dev/ttS1 c 4 65. A /dev/ttyS1 shows up in the directory
listing, but I am unable to
transmit/receive characters on it.

Thanks.

Scott Wood-2 wrote:

On Tue, Aug 25, 2009 at 08:37:11AM -0700, AGKohler wrote:

Hello,

I am working with a mpc8260ads(actually QUICC 8248 processor) based
board.
There are two hardware rs-232 ports available.
I can switch the console between the two by switching the
CONFIG_CONS_INDEX
configuration variable between 1 and 4.
I would like to have both ports in service, when Linux comes up. One as
the
console and the second to communicate with(i.e. acquire data from) a
third
party rs-232 device. Eventually, the third party device may be a
telephone
modem. Can anyone explain how to accomplish this, and if not, what
constraints are blocking the accomplishment of my requirements. Any
suggestions will be appreciated.

This isn't a U-Boot issue, except insofar as U-Boot passes a device tree
to Linux (assuming it does even that -- you don't mention which kernel or
u-boot version you're using).

If your device tree contains both serial ports, then Linux should be able
to use them both. If it doesn't work, make sure all the pins are
configured correctly, typically by Linux platform code for your board
(though ideally U-Boot should set them up as well).

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

--
View this message in context:
http://www.nabble.com/How-can-I-make-a-second-serial-port-on-a-motorola-8248-Chip-known-to-Linux.-tp25136771p25157108.html
Sent from the Uboot - Users mailing list archive at Nabble.com.

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

[U-Boot] [RFC PATCH 3/3] phylib: add generic phy driver

2009-08-26 Thread Jean-Christophe PLAGNIOL-VILLARD

this driver must be the last one registered to be the last one probed

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
---
 drivers/net/phy/Makefile  |1 +
 drivers/net/phy/generic.c |   35 +++
 drivers/net/phy/phylib.c  |8 
 include/phydev.h  |5 +
 4 files changed, 49 insertions(+), 0 deletions(-)
 create mode 100644 drivers/net/phy/generic.c

diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index c8abc21..987504f 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -25,6 +25,7 @@ include $(TOPDIR)/config.mk
 
 LIB:= $(obj)libphy.a
 
+COBJS-$(CONFIG_PHY_GENERIC) += generic.o
 COBJS-$(CONFIG_BITBANGMII) += miiphybb.o
 COBJS-$(CONFIG_MV88E61XX_SWITCH) += mv88e61xx.o
 COBJS-$(CONFIG_MII) += miidev.o
diff --git a/drivers/net/phy/generic.c b/drivers/net/phy/generic.c
new file mode 100644
index 000..0d8f69c
--- /dev/null
+++ b/drivers/net/phy/generic.c
@@ -0,0 +1,35 @@
+/*
+ * Copyright (c) 2009 Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ *
+ */
+
+#include common.h
+#include phydev.h
+
+void generic_phy_register(void)
+{
+   struct phy_driver generic_phy = {
+   .name = Generic PHY,
+   .phy_id = 0x,
+   .phy_id_mask = 0x,
+   .features = 0,
+   .config_init = generic_phy_init,
+   };
+
+   phy_driver_register(generic_phy);
+}
diff --git a/drivers/net/phy/phylib.c b/drivers/net/phy/phylib.c
index 100c6c5..e6d1b8c 100644
--- a/drivers/net/phy/phylib.c
+++ b/drivers/net/phy/phylib.c
@@ -52,6 +52,14 @@ int phy_init(void)
/* Initialize the list */
INIT_LIST_HEAD(phy_drvs.list);
 
+   /*
+* this generic phy driver must be the last one registered to be
+* the last one probed
+*/
+#ifdef CONFIG_PHY_GENERIC
+   generic_phy_register();
+#endif
+
return 0;
 }
 
diff --git a/include/phydev.h b/include/phydev.h
index b15e138..fb06142 100644
--- a/include/phydev.h
+++ b/include/phydev.h
@@ -116,4 +116,9 @@ int genphy_restart_aneg(struct phy_device *phydev);
 int genphy_setup_forced(struct phy_device *phydev);
 int genphy_update_link(struct phy_device *phydev);
 
+/*
+ * Phy register functions
+ */
+void generic_phy_register(void);
+
 #endif /* __PHYDEV_H__ */
-- 
1.6.3.1

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

[U-Boot] [RFC PATCH 2/3] net: add phylib implementation

2009-08-26 Thread Jean-Christophe PLAGNIOL-VILLARD

the current implementation will allow you to probe, instance and mananage
one phy_device per mii_device

this implementation is based on the linux implementation done by Andy Fleming

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
---
 drivers/net/phy/Makefile |1 +
 drivers/net/phy/phylib.c |  535 ++
 include/linux/ethtool.h  |  172 +++
 include/linux/mii.h  |  392 --
 include/miidev.h |1 +
 include/phydev.h |  119 ++
 6 files changed, 1060 insertions(+), 160 deletions(-)
 create mode 100644 drivers/net/phy/phylib.c
 create mode 100644 include/linux/ethtool.h
 rewrite include/linux/mii.h (67%)
 create mode 100644 include/phydev.h

diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index 6775e44..c8abc21 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -29,6 +29,7 @@ COBJS-$(CONFIG_BITBANGMII) += miiphybb.o
 COBJS-$(CONFIG_MV88E61XX_SWITCH) += mv88e61xx.o
 COBJS-$(CONFIG_MII) += miidev.o
 COBJS-$(CONFIG_CMD_MII) += miidev.o
+COBJS-$(CONFIG_NET_PHYLIB) += phylib.o
 
 COBJS  := $(sort $(COBJS-y))
 SRCS   := $(COBJS:.o=.c)
diff --git a/drivers/net/phy/phylib.c b/drivers/net/phy/phylib.c
new file mode 100644
index 000..100c6c5
--- /dev/null
+++ b/drivers/net/phy/phylib.c
@@ -0,0 +1,535 @@
+/*
+ * drivers/net/phy/phy_device.c
+ *
+ * Framework for finding and configuring PHYs.
+ * Also contains generic PHY driver
+ *
+ * Copyright (c) 2009 Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
+ *
+ * Author: Andy Fleming
+ *
+ * Copyright (c) 2004 Freescale Semiconductor, Inc.
+ *
+ * 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.
+ *
+ */
+
+#include common.h
+#include net.h
+#include malloc.h
+#include miidev.h
+#include phydev.h
+
+#define PHY_AN_TIMEOUT (10 * CONFIG_SYS_HZ)
+
+static struct phy_driver phy_drvs;
+static int genphy_config_init(struct phy_device *phydev);
+
+int phy_driver_register(struct phy_driver *phydrv)
+{
+   if(!phydrv)
+   return -1;
+
+   list_add_tail(phydrv-list, phy_drvs.list);
+
+   if (!phydrv-config_init)
+   phydrv-config_init = genphy_config_init;
+
+   if (!phydrv-config_aneg)
+   phydrv-config_aneg = genphy_config_aneg;
+
+   if (!phydrv-read_status)
+   phydrv-read_status = genphy_read_status;
+
+   return 0;
+}
+
+int phy_init(void)
+{
+   /* Initialize the list */
+   INIT_LIST_HEAD(phy_drvs.list);
+
+   return 0;
+}
+
+static struct phy_device* phy_search(struct mii_device *miidev, unsigned int 
id)
+{
+   struct list_head *pos;
+   struct phy_driver *phydrv;
+   struct phy_device *phydev;
+
+   list_for_each(pos, phy_drvs.list) {
+   phydrv = list_entry(pos, struct phy_driver, list);
+   if ((id  phydrv-phy_id_mask) ==
+   (phydrv-phy_id  phydrv-phy_id_mask)) {
+   phydev = calloc(1, sizeof(struct phy_device));
+
+   if (!phydev)
+   return NULL;
+
+   phydev-phydrv = phydrv;
+   phydev-miidev = miidev;
+   phydev-phy_id = id;
+   return phydev;
+   }
+   }
+
+   return NULL;
+}
+
+static int phy_connect(struct mii_device *miidev, int phy_addr)
+{
+   struct phy_device* phydev;
+   unsigned int id1, id2, id;
+   unsigned int phyaddr = (phy_addr + 1u) % 32u;
+
+   id1 = mii_read(miidev, phyaddr, MII_PHYSID1);
+   id2 = mii_read(miidev, phyaddr, MII_PHYSID2);
+   id  = (id1  16) | (id2);
+   phydev = phy_search(miidev, id);
+
+   if (!phydev)
+   return -1;
+
+   phydev-addr = phyaddr;
+   phydev-miidev = miidev;
+   miidev-phydev = phydev;
+
+   printf(%s found at 0x%x\n, phydev-phydrv-name, phyaddr);
+
+   return 0;
+}
+
+/* Automatically gets and returns the PHY device */
+int phy_device_connect(struct mii_device *miidev, int phy_addr,
+   void (*adjust_link) (struct mii_device *miidev))
+{
+   struct phy_driver* phydrv;
+   struct phy_device* phydev;
+   unsigned int i;
+
+   if (!miidev-phydev) {
+   if (phy_addr = 0) {
+   if (phy_connect(miidev, phy_addr)  0)
+   goto fail;
+   }
+
+   for (i = 0; i  32; i++) {
+   if(!phy_connect(miidev, phy_addr))
+   break;
+   }
+
+   if (i == 32)
+   goto fail;
+
+   phydev = miidev-phydev;
+   phydrv = phydev-phydrv;
+
+

Re: [U-Boot] How can I make a second serial port on a motorola 8248 Chip known to Linux.

2009-08-26 Thread Scott Wood

On Wed, Aug 26, 2009 at 01:15:39PM -0700, AGKohler wrote:
 I am using u-boot version 1.1.3, kernel, Linux(Debian) is version 2.6.12.

Both of thosed are extremely old.  Our ability to help you with them is
very limited.  Please use the current code.

 I searched through the kernel configuration options via menuconfig, i could
 not find 
 anything that configures the number of serial ports. In LINUX, i tried
 creating ttyS1 with
 mknod -m 660 /dev/ttS1 c 4 65. A /dev/ttyS1 shows up in the directory
 listing, but I am unable to
 transmit/receive characters on it.

You want /dev/ttyCPM1, and you should use udev or equivalent to create
the device nodes.

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

[U-Boot] Pull request: nand flash next

2009-08-26 Thread Scott Wood

The following changes since commit d7f4d14a8b317857163ccf3d97e3b1a46ba2282e:
  Wolfgang Denk (1):
Merge branch 'next' of git://www.denx.de/git/u-boot-coldfire into next

are available in the git repository at:

  git://git.denx.de/u-boot-nand-flash.git next

Heiko Schocher (1):
  83xx, kmeter1: added NAND support

Ilya Yanok (1):
  mxc_nand: add nand driver for MX2/MX3

Kyungmin Park (1):
  OneNAND: Remove unused read_spareram

Matthias Kaehlcke (1):
  KB9202: Add NAND support

Sandeep Paulraj (3):
  NAND: ADD page Parameter to all read_page/read_page_raw API's
  MTD:NAND: ADD new ECC mode NAND_ECC_HW_OOB_FIRST
  NAND: DaVinci: V2 Adding 4 BIT ECC support

 drivers/mtd/nand/Makefile|3 +
 drivers/mtd/nand/davinci_nand.c  |  284 ++-
 drivers/mtd/nand/fsl_elbc_nand.c |2 +-
 drivers/mtd/nand/kb9202_nand.c   |  150 +
 drivers/mtd/nand/kmeter1_nand.c  |  135 +
 drivers/mtd/nand/mxc_nand.c  |  880 ++
 drivers/mtd/nand/nand_base.c |   75 +++-
 drivers/mtd/onenand/onenand_base.c   |4 +-
 include/asm-arm/arch-davinci/emif_defs.h |   10 +
 include/configs/kmeter1.h|6 +
 include/linux/mtd/nand.h |5 +-
 include/linux/mtd/onenand.h  |3 +-
 12 files changed, 1540 insertions(+), 17 deletions(-)
 create mode 100644 drivers/mtd/nand/kb9202_nand.c
 create mode 100644 drivers/mtd/nand/kmeter1_nand.c
 create mode 100644 drivers/mtd/nand/mxc_nand.c
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

2009-08-26 Thread Scott Wood

Wolfgang Denk wrote:
 Scott could you applied on your tree as this one need the nand patch that you
 handle
 
 Could you please run this through your next branch and send a pullr
 equest? TIA.
 
 Acked-by: Wolfgang Denk w...@denx.de

I don't have that patch in my inbox anymore -- but I've sent a pull 
request for what I do have in next.  You (or JC) should be able to 
apply this after pulling that.

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

Re: [U-Boot] [PATCH] Add ability for arch code to make changes before we boot

Dear Kumar Gala,

In message 1250276442-28463-1-git-send-email-ga...@kernel.crashing.org you 
wrote:
 Added a arch_preboot() function that cpu specific code can implement to
 allow for various modifications to the state of the machine right before
 we boot.  This can be useful to setup register state to a specific
 configuration.
 
 Signed-off-by: Kumar Gala ga...@kernel.crashing.org
 ---
  common/cmd_bootm.c |   10 ++
  1 files changed, 10 insertions(+), 0 deletions(-)
 
 diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
 index 86c8122..766889a 100644
 --- a/common/cmd_bootm.c
 +++ b/common/cmd_bootm.c
 @@ -166,6 +166,13 @@ void __arch_lmb_reserve(struct lmb *lmb)
  }
  void arch_lmb_reserve(struct lmb *lmb) __attribute__((weak, 
 alias(__arch_lmb_reserve)));
  
 +/* Allow for arch specific config before we boot */
 +void __arch_preboot(void)

As this is only used when booting an OS (and not for example when
starting a standalone program) we should probably write:

/* Allow for arch specific code before booting the OS */
void __arch_preboot_os()
...

 +{
 + /* please define platform specific arch_preboot() */
 +}
 +void arch_preboot(void) __attribute__((weak, alias(__arch_preboot)));
 +
  #if defined(__ARM__)
#define IH_INITRD_ARCH IH_ARCH_ARM
  #elif defined(__avr32__)
 @@ -543,6 +550,7 @@ int do_bootm_subcommand (cmd_tbl_t *cmdtp, int flag, int 
 argc, char *argv[])
   break;
   case BOOTM_STATE_OS_GO:

Hm... maybe this could / should be handled in BOOTM_STATE_OS_PREP
state? 

   disable_interrupts();
 + arch_preboot();

And maybe we should mode disable_interrupts() into the default
implementation of arch_preboot_os() ?

   boot_fn(BOOTM_STATE_OS_GO, argc, argv, images);
   break;
   }
 @@ -673,6 +681,8 @@ int do_bootm (cmd_tbl_t *cmdtp, int flag, int argc, char 
 *argv[])
   return 1;
   }
  
 + arch_preboot();
 +
   boot_fn(0, argc, argv, images);

But this would change behaviour here. Eventually to the better?

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
Niklaus Wirth has lamented that, whereas Europeans pronounce his name
correctly  (Ni-klows  Virt),  Americans  invariably  mangle  it  into
(Nick-les  Worth).  Which  is to say that Europeans call him by name,
but Americans call him by value.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] How can I make a second serial port on a motorola 8248 Chip known to Linux.

Dear AGKohler,

please do not top post-full quote.

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

And please note that this still off topic on this list. It is a LINUX
question, not an U-Boot one.


In message 25157108.p...@talk.nabble.com you wrote:
 
 I am using u-boot version 1.1.3, kernel, Linux(Debian) is version 2.6.12.

This is very, very old code, and you will probably find nobody willing
to spend time and efforts for free to deal with issues that have been
solved long, long ago.

Please update your code - say, use at least U-Boot v2009.03 (or later)
and Linux 2.6.30 (or later), and if you still have issues, please ask
on a Linux mailing list.

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] [PATCH v2] mpc83xx: update LCRR register handling

On Wed, 26 Aug 2009 08:28:37 +0200
Heiko Schocher h...@denx.de wrote:

 Hello Kim,
 
 Kim Phillips wrote:
  On Tue, 25 Aug 2009 13:31:34 +0200
  Heiko Schocher h...@denx.de wrote:
  +  /* MPC8379E RM 10-34 says after writting this register
  +   * the register should be reread and an isync should be
  +   * executed.
  +   */
  +  in_be32(im-lbus.lcrr);
  +  isync();
  
  in_be32 and friends does the isync for you.  In fact, you can probably
  do it in one fell swoop by using setbits/clrsetbits?
 
 Argh, of course. But I need the in_be32() for rereading the register
 again, as the RM says.

right on

  +++ b/include/mpc83xx.h
  @@ -198,6 +198,7 @@
   #define SICRL_URT_CTPR0x0600
   #define SICRL_IRQ_CTPR0x00C0
 
  +#define LCRR_MASK 0x0003000f
  
  I thought we discussed this - shouldn't this be 0x7fff?
 
 Hmm.. as I did this mpc832x specific, in my version it is not possible
 to set reserved 0 bits to 1 ... Ah, I reread your mail again, you wrote:
  I guess I have a shoot-yourself-in-the-foot philosophy - you're free to
  find out what happens when setting reserved bits to 1 if you so wish.
  u-boot protects you up to the point where you veer off into using
  hardcoded values instead of using the predefined CONFIG_SYS_SCCR_*
  macros.
 
 I think you mean the LCRR_* defines ...

yes, thank you

 Hmm... so we can say: feel free to find out what happens, if setting
 reserved 1 bits to 0! and can drop this patch ...

precisely - I'd rather have this kept in the board config file if at
all possible - that's how other 83xx boards do it atm.

 Hmmm, you can use for the mpc832x for example the LCRR_BUFCMDC_1,
 what is a valid define for mpc83xx, but it is not valid for the
 mpc832x ... so It is not the problem, that a u-boot user use hard-
 coded values, instead this processor don;t support all bits valid
 for other mpc83xx processors.
 
 So I tend to protect an u-boot user from doing wrong things,
 (setting reserved 0/1 bits to 1/0) if it is easy possible ...

right but:

o LCRR_PDYP, granted dangerous in your case, is obviously a writeable
bit (not read-only), and documented as such in later documentation.  In
fact, there are no non-writeable bits in LCRR.

o the user loses visibility into what is going on if they
decide to drop/add sensitive bits such as LCRR_DBYP in their board's
CONFIG_SYS_LCRR settings, and there's a mask lurking in the background.

o let's be practical here - in a board port, LCRR settings have to be
paid attention to, no matter what hidden behaviours or new bits there
are lying underneath - perhaps the form of 'protection' you seek is in
the form of a comment in the code?

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

Re: [U-Boot] [RFC PATCH 1/3] net: rework the mii support

On Wednesday 26 August 2009 16:13:01 Jean-Christophe PLAGNIOL-VILLARD wrote:
 this rework is done in order to add a phylib and reduce and simplify
 the implementation of multi net_device support for the same driver

i think you mean multi phy ...

 precedently we pass the device name to the miiphy_read/write  co

while the first word could be used, i think you mean presently

 now we pass the mii_device instance of the mii bus
 all network driver are switch to this way

if you're going to avoid punctuation in your commits, then separate sentences 
really need separate paragraphs

and the second sentence probably should be drivers are converted to this 
method

 we currently keep the old miiphy api by wrapping it to the new mii_device
 api until we have the phylib implementation and all the network driver
 using it

if the old method and header is deprecated, then you could add a #warning to 
the old header telling people to change

the changes to the Blackfin MAC driver looks sane to me, thanks
-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] [RFC PATCH 2/3] net: add phylib implementation

On Wednesday 26 August 2009 16:13:02 Jean-Christophe PLAGNIOL-VILLARD wrote:
 the current implementation will allow you to probe, instance and mananage
 one phy_device per mii_device

instance - instantiate
mananage - manage

 --- /dev/null
 +++ b/drivers/net/phy/phylib.c
 @@ -0,0 +1,535 @@
 +/*
 + * drivers/net/phy/phy_device.c

needs updating

 +static int genphy_config_init(struct phy_device *phydev);

why does _init() have a static def in this C file but the other genhy_config_* 
funcs have a non-static def in the H file

 +int phy_driver_register(struct phy_driver *phydrv)
 +{
 + if(!phydrv)

missing space

 +int phy_init(void)
 +{
 + /* Initialize the list */
 + INIT_LIST_HEAD(phy_drvs.list);

does it really need to be dynamic ?  arent there static initializers so this 
can be done in .data ?

 + phydev = calloc(1, sizeof(struct phy_device));

this is odd style.  why dont we stop jerkin around in all our code and 
introduce zalloc() already.  the first patch in this series has malloc/memset 
usage too.

 +static int phy_connect(struct mii_device *miidev, int phy_addr)
 +{
 + unsigned int phyaddr = (phy_addr + 1u) % 32u;

what's this business all about ?  why wrap the phy addr ?

 + printf(%s found at 0x%x\n, phydev-phydrv-name, phyaddr);

0x%x - %#x

 + for (i = 0; i  32; i++) {

i'd stick a comment here about mii bus being limited to 7 bits as not everyone 
knows it

 + if(!phy_connect(miidev, phy_addr))
 + if(phydrv-config_init)

missing space after the if

 + printf(%dMbps %s duplex link detected\n, phydev-speed,
 + phydev-duplex? full : half);

need space before the ?

 + } else {
 + printf(*Warning* no link detected\n);
 + }
 +
 + return 0;

should no link really return success ?

 + if (phydev-duplex == DUPLEX_FULL){

need space before that {

 + result = genphy_config_advert(phydev);
 +
 + if (result  0) /* error */
 + return result;

the error comment seems kind of useless

 + /* Only restart aneg if we are advertising something different
 +  * than we were before.  */

embedded tab at the end of the comment doesnt belong

 + now = get_timer(0);
 + while (get_timer(now)  PHY_AN_TIMEOUT) {

kind of useless to check the timer right away.  please convert to a do {...} 
while rather than a while {...}.

 + puts(PHY remote fault detected\n);
 + /* Restart auto-negotiation */
 + puts(PHY restarting auto-negotiation\n);

combine the puts()

 +#define ETHTOOL_GSET 0x0001 /* Get settings. */

i dont think we need all this ETHTOOL_xxx junk

 +/* compatibility with older code */
 +#define SPARC_ETH_GSET   ETHTOOL_GSET
 +#define SPARC_ETH_SSET   ETHTOOL_SSET

or this

 +/* Wake-On-Lan options. */
 +#define WAKE_PHY (1  0)
 +#define WAKE_UCAST   (1  1)
 +#define WAKE_MCAST   (1  2)
 +#define WAKE_BCAST   (1  3)
 +#define WAKE_ARP (1  4)
 +#define WAKE_MAGIC   (1  5)
 +#define WAKE_MAGICSECURE (1  6) /* only meaningful if WAKE_MAGIC */

does WOL really make sense in u-boot ?
-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] [RFC PATCH 3/3] phylib: add generic phy driver

On Wednesday 26 August 2009 16:13:03 Jean-Christophe PLAGNIOL-VILLARD wrote:
 +void generic_phy_register(void)
 +{
 + struct phy_driver generic_phy = {
 + .name = Generic PHY,
 + .phy_id = 0x,
 + .phy_id_mask = 0x,
 + .features = 0,
 + .config_init = generic_phy_init,
 + };
 +
 + phy_driver_register(generic_phy);

you cant register a driver you declared on the stack
-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] mpc83xx: match dtb filename references to their dts equivalents in the linux kernel

On Fri, 21 Aug 2009 17:38:38 -0500
Kim Phillips kim.phill...@freescale.com wrote:

 Signed-off-by: Kim Phillips kim.phill...@freescale.com
 ---

applied.

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

Re: [U-Boot] [PATCH] mpc83xx: mpc8349itx - accommodate larger kernel sizes unzero the bootdelay

On Mon, 24 Aug 2009 14:32:18 -0500
Kim Phillips kim.phill...@freescale.com wrote:

 apparently the ITX was missed last round.
 
 Also make bootdelay consistent with other boards, so as to give on the
 opportunity to fix mistakenly set bootcmd without having checked for an
 bootdelay zero setting first.
 
 Signed-off-by: Kim Phillips kim.phill...@freescale.com
 ---

applied.

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

[U-Boot] Please pull u-boot-mpc83xx.git

Hi Wolfgang Denk,

Please pull a couple of minor fix patches for the upcoming release:

The following changes since commit 85f9823cd74bd2d9a7854ca0b2244e43b5214e5a:
  Wolfgang Denk (1):
Merge branch 'master' of git://git.denx.de/u-boot-ppc4xx

are available in the git repository at:

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

Kim Phillips (2):
  mpc83xx: match dtb filename references to their dts equivalents in the 
linux kernel
  mpc83xx: mpc8349itx - accommodate larger kernel sizes  unzero the 
bootdelay

 include/configs/MPC8349EMDS.h |2 +-
 include/configs/MPC8349ITX.h  |6 +++---
 include/configs/MPC8360ERDK.h |2 +-
 3 files changed, 5 insertions(+), 5 deletions(-)

Thanks,

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

Re: [U-Boot] [PATCH 5/7] Make a special uboot used for booting from SDcard or SPI flash

2009-08-26 Thread Hu Mingkai-B21284

Hi Wolfgang,

First truly sorry for the long time delay. I'm not on purpose.

I reworked this patch and unified the implementation of booting from
NAND/SDCard/SPI flash
for MPC85xx platform, and sent to the U-Boot list on August:
http://lists.denx.de/pipermail/u-boot/2009-August/058803.html

Also we tried a method that not to swamp the top level Makefile with
different configuration
options. Hope you can find some time to give some comments.

Please find comments inline about this patch.

 -Original Message-
 From: Wolfgang Denk [mailto:w...@denx.de] 
 Sent: Tuesday, March 17, 2009 8:31 PM
 To: Hu Mingkai-B21284
 Cc: Fleming Andy-AFLEMING; u-boot@lists.denx.de; 
 Subject: Re: [U-Boot] [PATCH 5/7] Make a special uboot used 
 for booting from SDcard or SPI flash
 
 Dear Hu Mingkai-B21284,
 
 In message 
 73839b4a0818e747864426270ac332c303e41...@zmy16exm20.fsl.frees
 cale.net you wrote:
 
   Cannot this be done with U-Boot, or with Linux running on 
 any other 
   system that das a SDCard reader/writer attached to it?
 
  It's hard to do that, in order to support booting from the 
 SDCard, we 
  place the data structure onto the unused space on the MBR on the 
  SDCard.
 
 What exactly is the difficault part there?
 
 Reading and modifying the MBR is just like reading or writing 
 any other block on the device. Where is the problem?
 

Yes, you're right. We just need to put the specific info to the assigned
address.

@@ -2360,6 +2360,18 @@ ATUM8548_config: unconfig
 MPC8536DS_config:   unconfig
@$(MKCONFIG) $(@:_config=) ppc mpc85xx 
 mpc8536ds freescale
 
+MPC8536DS_SPIFLASH_config \
+MPC8536DS_SDCARD_config:   unconfig
+   @echo  $(obj)include/config.h;
+   @if [ $(findstring _SPIFLASH_,$@) ] ; then \
+   echo #define CONFIG_SPIFLASH_U_BOOT 
   $(obj)include/config.h ; \
+   fi ;
+   @echo #define CONFIG_SDCARD_U_BOOT  
 $(obj)include/config.h ;
+   @$(MKCONFIG) -a MPC8536DS ppc mpc85xx mpc8536ds 
 freescale ; \
+   echo TEXT_BASE = 0x11001000 
   $(obj)board/freescale/mpc8536ds/config.tmp ; \
+   echo #define CONFIG_SDCARD_U_BOOT 
   $(obj)include/config.h ;  \
+   echo CONFIG_SDCARD_U_BOOT = y 
   $(obj)include/config.mk ;
+
   
   Please do noty swamp the top level Makefile with configuration 
   options for one board.
   
 
  Could you give me some suggestion? ;-) Where is the proper 
 position to 
  handle this?
 
 Options if a board has (or uses) SPI flash and/or a SDCard 
 and/or other things belong into the board config file. It 
 makes no sense to provide long lists of make targets and then 
 again long code to analyze these options in the top level 
 Makefile. For example, above code would not allow for the 
 case that a customer wants to use a board with SPI flash 
 *and* SDCard - it covers only the *or* case. And no, please 
 do not attempt to add even more such targets. This is not the 
 way to go. It doesn't scale.
 
 Assume each of the hundrets of boards would add code like this.
 

So we add another option (-t) on the mkconfig file to parse the target
to individual targets,
and put them to config.h and config.mk, then leave the board config file
and board makefile
to handle the different options.
http://lists.denx.de/pipermail/u-boot/2009-August/058804.html

Really need your suggestions.

--- a/config.mk
+++ b/config.mk
@@ -112,8 +112,8 @@ DBGFLAGS= -g # -DDEBUG  OPTFLAGS= -Os 
#-fomit-frame-pointer  ifndef LDSCRIPT  #LDSCRIPT := 
$(TOPDIR)/board/$(BOARDDIR)/u-boot.lds.debug
-ifeq ($(CONFIG_NAND_U_BOOT),y)
-LDSCRIPT := $(TOPDIR)/board/$(BOARDDIR)/u-boot-nand.lds
+ifeq ($(CONFIG_SDCARD_U_BOOT),y)
+LDSCRIPT := $(TOPDIR)/board/$(BOARDDIR)/u-boot-sdboot.lds
 else
 LDSCRIPT := $(TOPDIR)/board/$(BOARDDIR)/u-boot.lds
 endif
   
   Is it absolutely necessary to set this in the top level config.mk 
   file?
   
  Maybe combined with u-boot.lds.
 
 Or moved to a processor or board specific config.mk.
 
 

Reused the u-boot.lds for booting from SDCard/SPI flash.

 Best regards,
 
 Wolfgang Denk
 

Sorry again for the delayed response.

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

Re: [U-Boot] [PATCH 3/7] eSPI: add eSPI controller support

2009-08-26 Thread Hu Mingkai-B21284

Hi Mike,

First truly sorry for the long time delay.
Please find comments inline.

 -Original Message-
 From: Mike Frysinger [mailto:vap...@gentoo.org] 
 Sent: Monday, March 16, 2009 6:06 PM
 To: Hu Mingkai-B21284
 Cc: u-boot@lists.denx.de; Jean-Christophe PLAGNIOL-VILLARD; 
 Fleming Andy-AFLEMING
 Subject: Re: [U-Boot] [PATCH 3/7] eSPI: add eSPI controller support

 On Monday 16 March 2009 04:56:22 Hu Mingkai-B21284 wrote:
  From: Mike Frysinger [mailto:vap...@gentoo.org]
   On Monday 16 March 2009 02:15:27 Jean-Christophe wrote:
On 10:52 Mon 16 Mar , Mingkai Hu wrote:
 Add eSPI controller support under the SPI framework.

 Signed-off-by: Mingkai Hu mingkai...@freescale.com
 ---
  drivers/mtd/spi/spi_flash.c |   94 +-
  drivers/spi/Makefile|1 +
  drivers/spi/fsl_espi.c  |  232
 +++ include/spi.h

   30 ++
  4 files changed, 354 insertions(+), 3 deletions(-)  
 create mode
 100644 drivers/spi/fsl_espi.c

please use the spi framework, their is no need to touch the 
spi_flash support ti add and use the fsl_espi

   indeed ... i was so happy to see the spansion driver i 
 glossed over 
   this ...
   those spi_flash.c changes are almost assuredly wrong and indicate 
   you arent fitting into the framework correctly.

  There is difference between the SPI and eSPI chip select signal.
  Generally, the SPI chip select is controlled by GPIO, so SW can 
  control when to assert the chip select signal and when to stop the 
  chip select signal.

 that is incorrect.  the SPI framework does not care how the 
 controller manages the CS.  the Blackfin SPI controller for 
 example has dedicated CS's which the controller manages automatically.

  But the eSPI controller integrate the chip select into the 
 controller 
  itself, it use the transfer length to control the duration 
 of the chip 
  select signal.

 so you must tell the controller ahead of time how many bytes 
 are going to be transferred ?  this sounds like a retarded 
 hardware implementation to me.  how exactly do you support 
 arbitrary transfer lengths ?

IIRC every transaction byte length control every transaction.

  The spi_flash_cmd_* function split the transfer into two 
 steps: first 
  the command transfer and then the data transfer. At the first step, 
  the transfer length is set to the command length, and when 
 transferred 
  the command, the chip select will be negated, so the eSPI 
 controller 
  thinks the transfer is cancelled and doesn't transfer the 
 data again.

 the transfer state is passed in via the flags parameter.  
 this way the SPI controller knows when a transfer starts 
 (SPI_XFER_BEGIN) and when it ends (SPI_XFER_END).
 -mike

As above, we can't use the start/end flags parameter.

Sorry again for the delayed response.

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

Re: [U-Boot] [PATCH] Add ability for arch code to make changes before we boot

2009-08-26 Thread Kumar Gala


On Aug 26, 2009, at 10:27 PM, Kumar Gala wrote:


 On Aug 26, 2009, at 3:46 PM, Wolfgang Denk wrote:

 Dear Kumar Gala,

 In message 1250276442-28463-1-git-send-email-ga...@kernel.crashing.org
 you wrote:
 Added a arch_preboot() function that cpu specific code can
 implement to
 allow for various modifications to the state of the machine right
 before
 we boot.  This can be useful to setup register state to a specific
 configuration.

 Signed-off-by: Kumar Gala ga...@kernel.crashing.org
 ---
 common/cmd_bootm.c |   10 ++
 1 files changed, 10 insertions(+), 0 deletions(-)

 diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
 index 86c8122..766889a 100644
 --- a/common/cmd_bootm.c
 +++ b/common/cmd_bootm.c
 @@ -166,6 +166,13 @@ void __arch_lmb_reserve(struct lmb *lmb)
 }
 void arch_lmb_reserve(struct lmb *lmb) __attribute__((weak,
 alias(__arch_lmb_reserve)));

 +/* Allow for arch specific config before we boot */
 +void __arch_preboot(void)

 As this is only used when booting an OS (and not for example when
 starting a standalone program) we should probably write:

  /* Allow for arch specific code before booting the OS */
  void __arch_preboot_os()
  ...

 no problem, will change the name.

 +{
 +   /* please define platform specific arch_preboot() */
 +}
 +void arch_preboot(void) __attribute__((weak,
 alias(__arch_preboot)));
 +
 #if defined(__ARM__)
  #define IH_INITRD_ARCH IH_ARCH_ARM
 #elif defined(__avr32__)
 @@ -543,6 +550,7 @@ int do_bootm_subcommand (cmd_tbl_t *cmdtp, int
 flag, int argc, char *argv[])
 break;
 case BOOTM_STATE_OS_GO:

 Hm... maybe this could / should be handled in BOOTM_STATE_OS_PREP
 state?

 I'd prefer to keep arch_preboot_os() as close to boot_fn() as possible

 disable_interrupts();
 +   arch_preboot();

 And maybe we should mode disable_interrupts() into the default
 implementation of arch_preboot_os() ?

 Got no issue with moving disable_interrupts into the default
 implementation of arch_preboot_os()

Now that I look at how do_bootm() calls and uses disable_interrupts()  
this is a bit more tricky.  I'd prefer to leave disable_interrupts()  
alone.

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

Re: [U-Boot] [U-boot][PATCH] AMCC ppc440SPe PCIe PLL lock error

Hi Wolfgang,

On Wednesday 26 August 2009 22:09:27 Wolfgang Denk wrote:
  u-boot reports a PCIE PLL lock error at boot time on Yucca
  board, and left PCIe nonfunctional. This is fixed by making u-boot
  function ppc4xx_init_pcie() to wait 300 uS after negating reset before
  the first check of PLL lock.
 
  This fix touches only one file 4xx_pcie.c
 
  Signed off by  Rupjyoti Sarmah  rsar...@amcc.com  from Applied Micro
  

 I did not see any comments from you to this, nor can I see it your
 repo?

This patch was shortly followed/replaced with an improved version:

2009-07-24: [U-Boot] [PATCH] ppc440SPe: PCIe PLL lock error

Link:
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/64820

This patch had some issues which I pointed out:

http://article.gmane.org/gmane.comp.boot-loaders.u-boot/64826

Unfortunately no answer till now. Rup, how about this one? Could you please 
send a new (fixed) version of this patch? Thanks.

Cheers,
Stefan

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

Re: [U-Boot] [PATCH] Add some second source legacy flash chips 256x8

Hi Wolfgang,

On Wednesday 26 August 2009 22:10:42 Wolfgang Denk wrote:
  We tested some boot flashes as possible second source.
  As some had ids above 0x7f, we had to implement JEDEC JEP106Z in
  cfi_flash.c. I now that I just missed the merge window, but the patches
  are not urgent and I was away for a three week
 
   drivers/mtd/cfi_flash.c   |   16 +--
   drivers/mtd/jedec_flash.c |   67
  + include/flash.h   |
10 ++-
   3 files changed, 89 insertions(+), 4 deletions(-)

 Any chance to pick this up for next?

This patch was superseded by this one:

Support up to 7 banks for ids as specified in JEDEC JEP106Z

which you pulled into next just last night.

Cheers,
Stefan

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

Re: [U-Boot] [RFC PATCH 2/3] net: add phylib implementation

On Thursday 27 August 2009 03:55:57 Mike Frysinger wrote:
  +int phy_init(void)
  +{
  +   /* Initialize the list */
  +   INIT_LIST_HEAD(phy_drvs.list);

 does it really need to be dynamic ?  arent there static initializers so
 this can be done in .data ?

Using static initializers fails on PPC because of the somewhat broken 
relocation. So this dynamic implementation is the preferred version, at least 
for PPC people.

Cheers,
Stefan

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

Re: [U-Boot] [PATCH 3/7] eSPI: add eSPI controller support

On Wednesday 26 August 2009 23:01:52 Hu Mingkai-B21284 wrote:
 From: Mike Frysinger [mailto:vap...@gentoo.org]
  On Monday 16 March 2009 04:56:22 Hu Mingkai-B21284 wrote:
   But the eSPI controller integrate the chip select into the controller 
   itself, it use the transfer length to control the duration of the chip
   select signal.
 
  so you must tell the controller ahead of time how many bytes
  are going to be transferred ?  this sounds like a retarded
  hardware implementation to me.  how exactly do you support
  arbitrary transfer lengths ?

 IIRC every transaction byte length control every transaction.

but what if you dont know the length of the transaction ahead of time ?  if 
you look at the spi flash framework, it'll write a few bytes (like the opcode 
to read the status register) and then it'll just keep reading 1 byte at a time 
(polling the status register).  there is no way of knowing the length ahead of 
time.  most of the SPI code in u-boot operates this way.

   The spi_flash_cmd_* function split the transfer into two steps: first
   the command transfer and then the data transfer. At the first step,
   the transfer length is set to the command length, and when transferred
   the command, the chip select will be negated, so the eSPI controller
   thinks the transfer is cancelled and doesn't transfer the data again.
 
  the transfer state is passed in via the flags parameter.
  this way the SPI controller knows when a transfer starts
  (SPI_XFER_BEGIN) and when it ends (SPI_XFER_END).

 As above, we can't use the start/end flags parameter.

then your controller wont be able to work with most (any?) of the code in u-
boot.  you need to reject every transfer that isnt done with both BEGIN and 
END flags set.
-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] [RFC PATCH 2/3] net: add phylib implementation