Re: [U-Boot] [PATCH] CFI Driver: Reset watchdog timer after each flash operation
Hi Ingo, On Friday 02 October 2009 12:34:17 Ingo van Lil wrote: The CFI driver does not reset the device's watchdog, so long-running flash operations will cause the watchdog timer to expire. A comment in flash_status_check() suggests that udelay() is expected to reset the watchdog, but I can't find any architecture where it does. PPC does it this way. udelay() in lib_ppc/time.c calls wait_ticks(). And here you will find WATCHDOG_RESET. Which platform are you using? I support this needs to be fixed in your platform. 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] ppc4xx: Reorganize DDR2 ECC handling
On Sunday 27 September 2009 23:56:12 Felix Radensky wrote: Reorganize DDR2 ECC handling to use common code for SPD DIMMs and soldered SDRAM. Also, use common code to display SDRAM info (ECC, CAS latency) for SPD and soldered SDRAM variants. Applied to u-boot-ppc4xx/master. 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: Merge PPC4xx DDR and DDR2 ECC handling
On Tuesday 29 September 2009 08:39:28 Stefan Roese wrote: This patch merges the ECC handling (ECC parity byte writing) into one file (ecc.c) for all PPC4xx SDRAM controllers except for PPC440EPx/GRx. This exception is because only those PPC's use the completely different Denali SDRAM controller core. Previously we had two routines to generate/write the ECC parity bytes. With this patch we now only have one core function left. Tested on Kilauea (no ECC) and Katmai (with and without ECC). Applied to u-boot-ppc4xx/master. 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: Add SDRAM detection for PMC440 boards
On Wednesday 30 September 2009 11:55:04 Matthias Fuchs wrote: This patch adds support to detect the amount of DDR2 SDRAM on PMC440 modules. Detection is done by probing through a list of available and supported hardware configurations from 1GByte down to 256MB. The static TLB entry is replaced by dynamically created entries. Applied to u-boot-ppc4xx/master. 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
[U-Boot] Please pull u-boot-ppc4xx/master
The following changes since commit 1d96cfe8f5eebfc6ea39d1a387f35ca4499e6b67: Wolfgang Denk (1): Merge branch 'master' of git://git.denx.de/u-boot-mpc85xx are available in the git repository at: git://www.denx.de/git/u-boot-ppc4xx.git master Felix Radensky (1): ppc4xx: Reorganize DDR2 ECC handling Matthias Fuchs (1): ppc4xx: Add SDRAM detection for PMC440 boards Stefan Roese (1): ppc4xx: Merge PPC4xx DDR and DDR2 ECC handling board/esd/pmc440/init.S | 11 +- board/esd/pmc440/sdram.c| 82 ++--- cpu/ppc4xx/44x_spd_ddr2.c | 366 --- cpu/ppc4xx/4xx_ibm_ddr2_autocalib.c |6 +- cpu/ppc4xx/ecc.c| 167 +++- cpu/ppc4xx/ecc.h| 52 +++--- include/asm-ppc/ppc4xx-sdram.h |7 +- include/configs/PMC440.h|1 - 8 files changed, 341 insertions(+), 351 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] CFI Driver: Reset watchdog timer after each flash operation
On 10/02/2009 01:06 PM, Stefan Roese wrote: The CFI driver does not reset the device's watchdog, so long-running flash operations will cause the watchdog timer to expire. A comment in flash_status_check() suggests that udelay() is expected to reset the watchdog, but I can't find any architecture where it does. PPC does it this way. udelay() in lib_ppc/time.c calls wait_ticks(). And here you will find WATCHDOG_RESET. You're right. Seems to be an exception, though: According to ctags there are 40 separate implementations of udelay(), and the ones in lib_ppc and lib_nios seem to be the only ones that actually do call WATCHDOG_RESET. Which platform are you using? I support this needs to be fixed in your platform. I'm using an Atmel AT91-based custom board, and the udelay() function can be found in cpu/arm926ejs/at91/timer.c. Unfortunately there's no central udelay() implementation in lib_arm. Regards, Ingo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] TI DaVinci DM646x: Adding initial support for DM6467 EVM
s-paul...@ti.com wrote: From: Sandeep Paulraj s-paul...@ti.com This patch adds the initial support for DM6467 EVM. Other features like NET and NAND support will be added as follow up patches. Signed-off-by: Sandeep Paulraj s-paul...@ti.com --- There are multiple flavours of the DM646x. The newest DM646x SOC can operate at 1 GHz. The DM6467 EVM from Spectrum Digital can be used for both speed grades of the DM646x SOC . The only change on the EVM being an oscilator that operated at a higher frequency. The same board file will be used to support both SOC's. Support for this feature will be added as follow up patches. Patches will also be sent to enable EMAC, NAND and other features. Makefile|3 + Needs an addition to MAKEALL and optionally Maintainers board/davinci/dm6467evm/Makefile| 52 ++ board/davinci/dm6467evm/config.mk |2 + board/davinci/dm6467evm/dm6467evm.c | 31 include/configs/davinci_dm6467evm.h | 131 +++ 5 files changed, 219 insertions(+), 0 deletions(-) create mode 100644 board/davinci/dm6467evm/Makefile create mode 100644 board/davinci/dm6467evm/config.mk create mode 100644 board/davinci/dm6467evm/dm6467evm.c create mode 100644 include/configs/davinci_dm6467evm.h diff --git a/Makefile b/Makefile index 0b61d05..dc797b0 100644 --- a/Makefile +++ b/Makefile @@ -2962,6 +2962,9 @@ davinci_dm355evm_config : unconfig davinci_dm365evm_config :unconfig @$(MKCONFIG) $(@:_config=) arm arm926ejs dm365evm davinci davinci +davinci_dm6467evm_config : unconfig + @$(MKCONFIG) $(@:_config=) arm arm926ejs dm6467evm davinci davinci + imx27lite_config:unconfig @$(MKCONFIG) $(@:_config=) arm arm926ejs imx27lite logicpd mx27 diff --git a/board/davinci/dm6467evm/Makefile b/board/davinci/dm6467evm/Makefile new file mode 100644 index 000..26b0705 --- /dev/null +++ b/board/davinci/dm6467evm/Makefile @@ -0,0 +1,52 @@ +# +# (C) Copyright 2000, 2001, 2002 +# Wolfgang Denk, DENX Software Engineering, w...@denx.de. +# +# Copyright (C) 2007 Sergey Kubushyn k...@koi8.net +# +# 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:= $(BOARD).o +SOBJS:= + +SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS)) +SOBJS:= $(addprefix $(obj),$(SOBJS)) + +$(LIB): $(obj).depend $(OBJS) $(SOBJS) + $(AR) $(ARFLAGS) $@ $(OBJS) $(SOBJS) + +clean: + rm -f $(SOBJS) $(OBJS) + +distclean: clean + rm -f $(LIB) core *.bak $(obj).depend + +# +# This is for $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/board/davinci/dm6467evm/config.mk b/board/davinci/dm6467evm/config.mk new file mode 100644 index 000..ca801c2 --- /dev/null +++ b/board/davinci/dm6467evm/config.mk @@ -0,0 +1,2 @@ +#Provide at least 16MB spacing between us and the Linux Kernel image +TEXT_BASE = 0x8108 diff --git a/board/davinci/dm6467evm/dm6467evm.c b/board/davinci/dm6467evm/dm6467evm.c new file mode 100644 index 000..9605818 --- /dev/null +++ b/board/davinci/dm6467evm/dm6467evm.c @@ -0,0 +1,31 @@ +/* + * Copyright (C) 2009 Texas Instruments Incorporated + * + * 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
Re: [U-Boot] [PATCH] TI DaVinci DM355: Fix Compilation warning for DM355 EVM
s-paul...@ti.com wrote:
From: Sandeep Paulraj s-paul...@ti.com
This patch fixes a compilation warning while compiling
the DM355 EVM.
Signed-off-by: Sandeep Paulraj s-paul...@ti.com
---
board/davinci/dm355evm/dm355evm.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/board/davinci/dm355evm/dm355evm.c
b/board/davinci/dm355evm/dm355evm.c
index 0a44748..87f284c 100644
--- a/board/davinci/dm355evm/dm355evm.c
+++ b/board/davinci/dm355evm/dm355evm.c
@@ -92,8 +92,8 @@ int board_eth_init(bd_t *bis)
static void nand_dm355evm_select_chip(struct mtd_info *mtd, int chip)
{
struct nand_chip*this = mtd-priv;
- u32 wbase = (u32) this-IO_ADDR_W;
- u32 rbase = (u32) this-IO_ADDR_R;
+ unsigned long wbase = (unsigned long) this-IO_ADDR_W;
+ unsigned long rbase = (unsigned long) this-IO_ADDR_R;
if (chip == 1) {
__set_bit(14, wbase);
Ack-ed.
Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] TI DaVinci DM365: Fix Compilation warning for DM365 EVM
s-paul...@ti.com wrote:
From: Sandeep Paulraj s-paul...@ti.com
This patch fixes a compilation warning while compiling
the DM365 EVM.
Signed-off-by: Sandeep Paulraj s-paul...@ti.com
---
board/davinci/dm365evm/dm365evm.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/board/davinci/dm365evm/dm365evm.c
b/board/davinci/dm365evm/dm365evm.c
index 5b97060..1e3a14f 100644
--- a/board/davinci/dm365evm/dm365evm.c
+++ b/board/davinci/dm365evm/dm365evm.c
@@ -79,8 +79,8 @@ int board_eth_init(bd_t *bis)
static void nand_dm365evm_select_chip(struct mtd_info *mtd, int chip)
{
struct nand_chip*this = mtd-priv;
- u32 wbase = (u32) this-IO_ADDR_W;
- u32 rbase = (u32) this-IO_ADDR_R;
+ unsigned long wbase = (unsigned long) this-IO_ADDR_W;
+ unsigned long rbase = (unsigned long) this-IO_ADDR_R;
if (chip == 1) {
__set_bit(14, wbase);
This looks familiar.. good job getting both cases.
Ack-ed.
Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] CFI Driver: Reset watchdog timer after each flash operation
Dear Ingo van Lil, In message 20091002103417.ga9...@zaphod.peppercon.de you wrote: The CFI driver does not reset the device's watchdog, so long-running flash operations will cause the watchdog timer to expire. A comment in flash_status_check() suggests that udelay() is expected to reset the watchdog, but I can't find any architecture where it does. Please have a closer look, then. On PowerPC, udelay() [lib_ppc/time.c] calls wait_ticks(), which in turn [lib_ppc/ticks.S] calls WATCHDOG_RESET If this is missing in other architectures, it should be fixed at the root cause, i. e. in udelay() or in the respective support routines. 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 As long as we're going to reinvent the wheel again, we might as well try making it round this time.- Mike Dennison ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ppc4xx: Fix msg initialization as root-complex failed upon PCIe scan
This message is printed upon PCIe bus scan, not only upon error, but also
if no PCIe device is detected at all. Since this is not an error, let's
remove this message in this case. We already have the message
link is not up. if there is no PCIe device present.
Signed-off-by: Stefan Roese s...@denx.de
---
board/amcc/canyonlands/canyonlands.c |3 +++
board/amcc/katmai/katmai.c |3 +++
board/amcc/kilauea/kilauea.c |3 +++
board/amcc/makalu/makalu.c |3 +++
board/amcc/yucca/yucca.c |3 +++
cpu/ppc4xx/4xx_pcie.c|3 ++-
6 files changed, 17 insertions(+), 1 deletions(-)
diff --git a/board/amcc/canyonlands/canyonlands.c
b/board/amcc/canyonlands/canyonlands.c
index f359d23..9495b62 100644
--- a/board/amcc/canyonlands/canyonlands.c
+++ b/board/amcc/canyonlands/canyonlands.c
@@ -28,6 +28,7 @@
#include asm/mmu.h
#include asm/4xx_pcie.h
#include asm/gpio.h
+#include asm/errno.h
extern flash_info_t flash_info[CONFIG_SYS_MAX_FLASH_BANKS]; /* info for FLASH
chips */
@@ -414,6 +415,8 @@ void pcie_setup_hoses(int busno)
ret = ppc4xx_init_pcie_endport(i);
else
ret = ppc4xx_init_pcie_rootport(i);
+ if (ret == -ENODEV)
+ continue;
if (ret) {
printf(PCIE%d: initialization as %s failed\n, i,
is_end_point(i) ? endpoint : root-complex);
diff --git a/board/amcc/katmai/katmai.c b/board/amcc/katmai/katmai.c
index bcef707..aa6d0ab 100644
--- a/board/amcc/katmai/katmai.c
+++ b/board/amcc/katmai/katmai.c
@@ -32,6 +32,7 @@
#include asm/io.h
#include asm/gpio.h
#include asm/4xx_pcie.h
+#include asm/errno.h
DECLARE_GLOBAL_DATA_PTR;
@@ -391,6 +392,8 @@ void pcie_setup_hoses(int busno)
ret = ppc4xx_init_pcie_endport(i);
else
ret = ppc4xx_init_pcie_rootport(i);
+ if (ret == -ENODEV)
+ continue;
if (ret) {
printf(PCIE%d: initialization as %s failed\n, i,
is_end_point(i) ? endpoint : root-complex);
diff --git a/board/amcc/kilauea/kilauea.c b/board/amcc/kilauea/kilauea.c
index 5ebe692..5cd822a 100644
--- a/board/amcc/kilauea/kilauea.c
+++ b/board/amcc/kilauea/kilauea.c
@@ -28,6 +28,7 @@
#include fdt_support.h
#include asm/processor.h
#include asm/io.h
+#include asm/errno.h
#if defined(CONFIG_PCI)
#include pci.h
@@ -317,6 +318,8 @@ void pcie_setup_hoses(int busno)
ret = ppc4xx_init_pcie_endport(i);
else
ret = ppc4xx_init_pcie_rootport(i);
+ if (ret == -ENODEV)
+ continue;
if (ret) {
printf(PCIE%d: initialization as %s failed\n, i,
is_end_point(i) ? endpoint : root-complex);
diff --git a/board/amcc/makalu/makalu.c b/board/amcc/makalu/makalu.c
index fb0e7b7..d4277dd 100644
--- a/board/amcc/makalu/makalu.c
+++ b/board/amcc/makalu/makalu.c
@@ -29,6 +29,7 @@
#include asm/gpio.h
#include asm/io.h
#include fdt_support.h
+#include asm/errno.h
#if defined(CONFIG_PCI)
#include pci.h
@@ -273,6 +274,8 @@ void pcie_setup_hoses(int busno)
ret = ppc4xx_init_pcie_endport(i);
else
ret = ppc4xx_init_pcie_rootport(i);
+ if (ret == -ENODEV)
+ continue;
if (ret) {
printf(PCIE%d: initialization as %s failed\n, i,
is_end_point(i) ? endpoint : root-complex);
diff --git a/board/amcc/yucca/yucca.c b/board/amcc/yucca/yucca.c
index 033bdd2..5c9d491 100644
--- a/board/amcc/yucca/yucca.c
+++ b/board/amcc/yucca/yucca.c
@@ -32,6 +32,7 @@
#include asm/processor.h
#include asm/io.h
#include asm/4xx_pcie.h
+#include asm/errno.h
#include yucca.h
@@ -830,6 +831,8 @@ void pcie_setup_hoses(int busno)
yucca_setup_pcie_fpga_rootpoint(i);
ret = ppc4xx_init_pcie_rootport(i);
}
+ if (ret == -ENODEV)
+ continue;
if (ret) {
printf(PCIE%d: initialization as %s failed\n, i,
is_end_point(i) ? endpoint : root-complex);
diff --git a/cpu/ppc4xx/4xx_pcie.c b/cpu/ppc4xx/4xx_pcie.c
index e880c28..19d2c7d 100644
--- a/cpu/ppc4xx/4xx_pcie.c
+++ b/cpu/ppc4xx/4xx_pcie.c
@@ -30,6 +30,7 @@
#include ppc4xx.h
#include asm/processor.h
#include asm-ppc/io.h
+#include asm/errno.h
#if (defined(CONFIG_440SPE) || defined(CONFIG_405EX) ||\
defined(CONFIG_460EX) || defined(CONFIG_460GT)) \
@@ -874,7 +875,7 @@ int ppc4xx_init_pcie_port(int port, int rootport)
val = SDR_READ(SDRN_PESDR_LOOP(port));
if (!(val 0x1000)) {
Re: [U-Boot] [PATCH] ppc4xx: Fix msg initialization as root-complex failed upon PCIe scan
Dear Stefan Roese, In message 1254486916-3040-1-git-send-email...@denx.de you wrote: This message is printed upon PCIe bus scan, not only upon error, but also if no PCIe device is detected at all. Since this is not an error, let's remove this message in this case. We already have the message link is not up. if there is no PCIe device present. Thanks. Acked-by: Wolfgang Denk w...@denx.de But looking at this patch, it seems that larger parts in this (supposedly) board-specific code are actually more or less identical. Should we not factor out such common code? 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 Real programmers don't comment their code. It was hard to write, it should be hard to understand. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] TI: DaVinci: Updating EMAC driver for DM365 and DM646x
s-paul...@ti.com wrote:
From: Sandeep Paulraj s-paul...@ti.com
The EMAC IP on DM365 and DM646x is slightly different from
that on DM644x. This patch updates the DaVinci EMAC driver
so that EMAC becomes operational on DM365 in U-Boot.
A flag 'CONFIG_DAVINCI_EMAC_VERSION2' is used in the driver.
This flag will need to be defined in the DM365 config file.
Signed-off-by: Sandeep Paulraj s-paul...@ti.com
---
The same modifications work on DM646x in a slightly older version
of U-Boot. So when enabled this should work on the DM6467 EVM as well.
This has at this point of time not been tested on the DM6467 in the latest
version of U-Boot.
drivers/net/davinci_emac.c | 79 ++-
1 files changed, 77 insertions(+), 2 deletions(-)
diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index fa8cee4..0d61c91 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -107,6 +107,33 @@ static void davinci_eth_mdio_enable(void)
while (adap_mdio-CONTROL MDIO_CONTROL_IDLE) {;}
checkpatch complains here.
infinite loop statement should be on the next line.
ERROR: trailing statements should be on next line
#44: FILE: drivers/net/davinci_emac.c:119:
+ while ((adap_mdio-USERACCESS0 MDIO_USERACCESS0_GO) != 0);
}
+/* Read a PHY register via MDIO inteface */
+static int mdio_read(int phy_addr, int reg_num)
+{
+ adap_mdio-USERACCESS0 = MDIO_USERACCESS0_GO |
+ MDIO_USERACCESS0_WRITE_READ |
+ ((reg_num 0x1F) 21) |
+ ((phy_addr 0x1F) 16);
+
+ /* Wait for command to complete */
+ while ((adap_mdio-USERACCESS0 MDIO_USERACCESS0_GO) != 0);
+
+ return adap_mdio-USERACCESS0 0x;
+}
+
+/* Write to a PHY register via MDIO inteface */
+void mdio_write(int phy_addr, int reg_num, unsigned int data)
+{
+ /* Wait for User access register to be ready */
+ while ((adap_mdio-USERACCESS0 MDIO_USERACCESS0_GO) != 0);
checkpatch complains here.
infinite loop statement should be on the next line.
ERROR: trailing statements should be on next line
#53: FILE: drivers/net/davinci_emac.c:128:
+ while ((adap_mdio-USERACCESS0 MDIO_USERACCESS0_GO) != 0);
+
+ adap_mdio-USERACCESS0 = MDIO_USERACCESS0_GO |
+ MDIO_USERACCESS0_WRITE_WRITE |
+ ((reg_num 0x1F) 21) |
+ ((phy_addr 0x1F) 16) |
+ (data 0x);
+}
+
/*
* Tries to find an active connected PHY. Returns 1 if address if found.
* If no active PHY (or more than one PHY) found returns 0.
@@ -248,6 +275,31 @@ static int davinci_mii_phy_write(char *devname, unsigned
char addr, unsigned cha
#endif
+static void emac_gigabit_enable(void)
+{
+ int temp;
+
+ temp = mdio_read(EMAC_MDIO_PHY_NUM, 0);
+
+ if (temp (1 6)) {
Is there a logical #define bitfield that could be used here ?
+ /*
+ * Check if link detected is giga-bit
+ * If Gigabit mode detected, enable gigbit in MAC and PHY
+ */
+ adap_emac-MACCONTROL |= EMAC_MACCONTROL_GIGFORCE |
+ EMAC_MACCONTROL_GIGABIT_ENABLE;
+
+ /*
+ * The SYS_CLK which feeds the SOC for giga-bit operation
+ * does not seem to be enabled after reset as expected.
+ * Force enabling SYS_CLK by writing to the PHY
+ */
+ temp = mdio_read(EMAC_MDIO_PHY_NUM, 22);
+ temp |= (1 4);
+ mdio_write(EMAC_MDIO_PHY_NUM, 22, temp);
+ }
+}
+
/* Eth device open */
static int davinci_eth_open(struct eth_device *dev, bd_t *bis)
@@ -261,10 +313,15 @@ static int davinci_eth_open(struct eth_device *dev,
bd_t *bis)
/* Reset EMAC module and disable interrupts in wrapper */
adap_emac-SOFTRESET = 1;
while (adap_emac-SOFTRESET != 0) {;}
checkpatch complains here.
infinite loop statement should be on the next line.
ERROR: trailing statements should be on next line
#103: FILE: drivers/net/davinci_emac.c:318:
+ while (adap_ewrap-SOFTRST != 0);
+#if defined(CONFIG_DAVINCI_EMAC_VERSION2)
+ adap_ewrap-SOFTRST = 1;
+ while (adap_ewrap-SOFTRST != 0);
+#else
adap_ewrap-EWCTL = 0;
for (cnt = 0; cnt 5; cnt++) {
clkdiv = adap_ewrap-EWCTL;
}
+#endif
You may want to handle this like
#if defined(CONFIG_DAVINIC_EMAC_VERSION) CONFIG_DAVINCI_EMAC_VERSION = 2
rx_desc = emac_rx_desc;
@@ -282,6 +339,10 @@ static int davinci_eth_open(struct eth_device *dev, bd_t
*bis)
adap_emac-MACADDRLO =
(davinci_eth_mac_addr[5] 8) |
(davinci_eth_mac_addr[4]);
+#if
Re: [U-Boot] [PATCH] ppc4xx: Fix msg initialization as root-complex failed upon PCIe scan
Hi Wolfgang, On Friday 02 October 2009 14:41:58 Wolfgang Denk wrote: But looking at this patch, it seems that larger parts in this (supposedly) board-specific code are actually more or less identical. Should we not factor out such common code? Yes, this could (should) be done. But there are differences in these board specific functions. This consolidation could introduce new errors/bugs. And I didn't want to do such a thing, now that the merge window is closed. And frankly, I don't have the time for such a cleanup right now. But I'll put this on my to-do list. 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] TI: DaVinci DM365: Flag for updated EMAC driver.
s-paul...@ti.com wrote: From: Sandeep Paulraj s-paul...@ti.com The flag CONFIG_DAVINCI_EMAC_VERSION2 is used by the DaVinci EMAC driver to differentiate between different versions of the IP. Signed-off-by: Sandeep Paulraj s-paul...@ti.com --- include/configs/davinci_dm365evm.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/configs/davinci_dm365evm.h b/include/configs/davinci_dm365evm.h index 2797f82..643d26c 100644 --- a/include/configs/davinci_dm365evm.h +++ b/include/configs/davinci_dm365evm.h @@ -57,6 +57,7 @@ /* Network Configuration */ #define CONFIG_DRIVER_TI_EMAC +#define CONFIG_DAVINCI_EMAC_VERSION2 #define CONFIG_MII #define CONFIG_BOOTP_DEFAULT #define CONFIG_BOOTP_DNS This is fine if you do not change the logic in the previous patch which would require this to change to #define CONFIG_DAVINCI_EMAC_VERSION 2 Either way is fine. Ack Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] TI DaVinci DM646x: Adding initial support for DM6467 EVM
Patches will also be sent to enable EMAC, NAND and other features. Makefile|3 + Needs an addition to MAKEALL and optionally Maintainers Ok I will add diff --git a/include/configs/davinci_dm6467evm.h b/include/configs/davinci_dm6467evm.h new file mode 100644 index 000..c23d533 --- /dev/null +++ b/include/configs/davinci_dm6467evm.h @@ -0,0 +1,131 @@ +/* + * Copyright (C) 2009 Texas Instruments Incorporated - http://www.ti.com/ Above copyright did not have the http. You should be consistent. Add or remove, your choice. Ok I will rectify + +/* SoC Configuration */ +#define CONFIG_ARM926EJS /* arm926ejs CPU */ +#define CONFIG_SYS_TIMERBASE 0x01c21400 /* use timer 0 */ Is there a logical register #define you could use instead of the magic number? I can include the hardware.h and get the value from there, but the way the hardware.h for DaVinci has evolved over the years, including it in the config will result in compilation failure. I'll add this to my TODO list and send in a patch to clean up for all DaVinci SOC's the moment I get some free cycles. + +/* I2C Configuration */ +#define CONFIG_HARD_I2C +#define CONFIG_DRIVER_DAVINCI_I2C +#define CONFIG_SYS_I2C_SPEED 8 This speed is unusual. The same speed has been used with a slightly older version of U-boot and has worked fine davinci_sonata.h has a comment that it had a silicon bug with 100k Could the same comment be applied here ? I don't believe so +/* U-Boot general configuration */ +#undef CONFIG_USE_IRQ /* No IRQ/FIQ in U-Boot */ There is a TAB between #undef and CONFIG_USB_IRQ. Other undef's here use a space. Ok will fix. +#define CONFIG_BOOTDELAY 3 +#define CONFIG_BOOTFILEuImage/* Boot file name */ +#define CONFIG_SYS_PROMPT DM6467 EVM /* Monitor Command Prompt */ +#define CONFIG_SYS_CBSIZE 1024/* Console I/O Buffer Size */ +#define CONFIG_SYS_PBSIZE \ + (CONFIG_SYS_CBSIZE + sizeof(CONFIG_SYS_PROMPT) + 16) +#define CONFIG_SYS_MAXARGS 16 +#define CONFIG_VERSION_VARIABLE +#define CONFIG_AUTO_COMPLETE +#define CONFIG_SYS_HUSH_PARSER +#define CONFIG_SYS_PROMPT_HUSH_PS2 +#define CONFIG_CMDLINE_EDITING +#define CONFIG_SYS_LONGHELP +#define CONFIG_CRC32_VERIFY +#define CONFIG_MX_CYCLIC +#define CONFIG_BOOTCOMMAND source 0x8208; dhcp; bootm 3 spaces at the end of CONFIG_BOOTCOMMAND can be removed. Will fix Tom Thanks, Sandeep ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] TI DaVinci DM646x: Adding initial support for DM6467 EVM
Paulraj, Sandeep wrote: snip + +/* SoC Configuration */ +#define CONFIG_ARM926EJS /* arm926ejs CPU */ +#define CONFIG_SYS_TIMERBASE 0x01c21400 /* use timer 0 */ Is there a logical register #define you could use instead of the magic number? I can include the hardware.h and get the value from there, but the way the hardware.h for DaVinci has evolved over the years, including it in the config will result in compilation failure. I'll add this to my TODO list and send in a patch to clean up for all DaVinci SOC's the moment I get some free cycles. That is fine. + +/* I2C Configuration */ +#define CONFIG_HARD_I2C +#define CONFIG_DRIVER_DAVINCI_I2C +#define CONFIG_SYS_I2C_SPEED 8 This speed is unusual. The same speed has been used with a slightly older version of U-boot and has worked fine davinci_sonata.h has a comment that it had a silicon bug with 100k Could the same comment be applied here ? I don't believe so Ok fine as-is. Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Make arm926ejs use -mabi=apcs-gnu to avoid EABI problems
On Thu, 01 Oct 2009 20:27:11 +0200 Wolfgang Denk w...@denx.de wrote: -PLATFORM_CPPFLAGS += -march=armv5te +PLATFORM_CPPFLAGS += -march=armv5te -mabi=apcs-gnu I have to admit that I really hesitate ifwe should add this - the longer I think about it, the more I tend to say no. I call upon everybody who has some time and resources and who is able to reproduce the problem (so far I was not) to help and dig into this, so we can understand what's going on, and finally fix the cause of the problem, instead of trying to hush it up. OK, I understand. I meant to take a look at this today again, but got busy with other things. I'll try to get some time for this again next week. // Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Freescale MXC: NAND UnCorrectable RS-ECC Error
Hi All,
I am trying to introduce a Samsung NAND flash part (K9F8G08U0M) to a
Freescale mxc platform. Looks like the device code used in the NAND
read id operation is already a part of the
drivers/mtd/nand/nand_ids.c, looking at line {NAND 1GiB 3,3V 8-bit,
0xD3, 0, 1024, 0, LP_OPTIONS},) Its different in the sense that it
has a page size of 4K but the code specific to 4k page size handling
seems to be there in the code
After booting out of RAM, i am getting UnCorrectable RS-ECC Error
during an initial page read operation.
Am i missing something related to spare area/OOB.
Please let me know the fastest path to or get around or debug this issue.
NAND: UnCorrectable RS-ECC Error
Bad block table found at page 262080, version 0x01
UnCorrectable RS-ECC Error
UnCorrectable RS-ECC Error
Bad block table found at page 262016, version 0x01
UnCorrectable RS-ECC Error
UnCorrectable RS-ECC Error
nand_read_bbt: Bad block at 0x1e08
nand_read_bbt: Bad block at 0x1e0c
nand_read_bbt: Bad block at 0x1e30
nand_read_bbt: Bad block at 0x1e34
nand_read_bbt: Bad block at 0x2334
nand_read_bbt: Bad block at 0x3694
nand_read_bbt: Bad block at 0x3698
nand_read_bbt: Bad block at 0x369c
nand_read_bbt: Bad block at 0x36a0
nand_read_bbt: Bad block at 0x3ad0
nand_read_bbt: Bad block at 0x3ad4
nand_read_bbt: Bad block at 0x3ad8
nand_read_bbt: Bad block at 0x3f70
nand_read_bbt: Bad block at 0x3f74
nand_read_bbt: Bad block at 0x3f80
nand_read_bbt: Bad block at 0x3f84
nand_read_bbt: Bad block at 0x3f88
nand_read_bbt: Bad block at 0x3f90
nand_read_bbt: Bad block at 0x3f9c
nand_read_bbt: Bad block at 0x3fa4
nand_read_bbt: Bad block at 0x3fa8
nand_read_bbt: Bad block at 0x3fac
nand_read_bbt: Bad block at 0x3fb0
nand_read_bbt: Bad block at 0x3fb4
nand_read_bbt: Bad block at 0x3fb8
nand_read_bbt: Bad block at 0x3fc4
nand_read_bbt: Bad block at 0x3fc8
nand_read_bbt: Bad block at 0x3fd0
nand_read_bbt: Bad block at 0x3fd4
nand_read_bbt: Bad block at 0x3fe8
nand_read_bbt: Bad block at 0x3ff0
nand_read_bbt: Bad block at 0x3ff4
nand_read_bbt: Bad block at 0x3ff8
nand_read_bbt: Bad block at 0x3ffc
1024 MiB
My gdb backtrace if it helps at all:
(gdb) bt
#0 mxc_nand_ecc_status (mtd=value optimized out) at mxc_nand.c:272
#1 0x87f0bfb0 in mxc_nand_command (mtd=0x87f29c90, command=0,
column=0, page_addr=0) at mxc_nand.c:924
#2 0x87f08dd0 in nand_do_read_ops (mtd=0x87f29c90, from=value
optimized out, ops=0x87f29e18) at nand_base.c:1197
#3 0x87f09a64 in nand_read (mtd=0x1000, from=13310103653403,
len=2280692324, retlen=0x87e5fef4, buf=0x87e627b8 '�' repeats 200
times...) at nand_base.c:1319
#4 0x87f13d18 in readenv (offset=262144, buf=0x87e627b8 '�' repeats
200 times...) at u-boot/include/nand.h:41
#5 0x87f13d88 in env_relocate_spec () at env_nand.c:349
#6 0x87f13b58 in env_relocate () at env_common.c:264
#7 0x87f01874 in start_armboot () at board.c:357
#8 0x8c18 in ?? ()
Thanks,
Alfred
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Freescale MXC: NAND UnCorrectable RS-ECC Error
Hi
2009/10/2 alfred steele alfred.jaq...@gmail.com:
Hi All,
I am trying to introduce a Samsung NAND flash part (K9F8G08U0M) to a
Freescale mxc platform. Looks like the device code used in the NAND
read id operation is already a part of the
drivers/mtd/nand/nand_ids.c, looking at line {NAND 1GiB 3,3V 8-bit,
0xD3, 0, 1024, 0, LP_OPTIONS},) Its different in the sense that it
has a page size of 4K but the code specific to 4k page size handling
seems to be there in the code
After booting out of RAM, i am getting UnCorrectable RS-ECC Error
during an initial page read operation.
Am i missing something related to spare area/OOB.
Please let me know the fastest path to or get around or debug this issue.
Which MXC platform are you using and does it support 4K page size? And
does mxc_nand.c support 4K page size?
/Magnus
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/4] ppc4xx: Overhaul for cmd reginfo
The command reginfo got an overhaul for the ppc4xx. It dumps all the relevant HW configuration registers (address, symbolic name, content). This allows to easily detect errors in *.h files and changes in the HW configuration. It is split in the following parts: - Cleanup some HW register names: Here you find all the changes in the include directory for new register names and adapting other ones to the names used by AMCC in their manuals, e.g. For 440EPx/GRPPC440EPx/GRX, Revision 1.15 â September 22, 2008 For PPC405GP Embedded Processor, Revision 1.02 â March 22, 2006 - Apply new HW register names Modify all existing *.c files to use the new register names - Rework cmd reginfo Here the real work done to improve the reginfo command. - respect 80-chars per line in ppc*.h files After running checkstyle.pl on the three previous patches I noted that in the *.h files there were a lot of long lines. This patch solves this problem. I tested the changes on my PPC405GPr board HCU4 and PPC440EPx board HCU5. Only ran MAKEALL 4xx as I have no other cross-compilers installed. The DMA-registers are not dumped for the PPC440. I know that I could spend not only many hours but weeks to cleanup all the PPC4xx register naming conventions. Niklaus Giger (4): ppc4xx: Cleanup some HW register names ppc_4xx: Apply new HW register names ppc4xx: Rework cmd reginfo ppc4xx: respect 80-chars per line in ppc*.h files board/amcc/bamboo/bamboo.c| 32 +- board/amcc/canyonlands/canyonlands.c | 22 +- board/amcc/ebony/ebony.c | 22 +- board/amcc/katmai/katmai.c| 22 +- board/amcc/luan/epld.h| 22 +- board/amcc/luan/luan.c| 22 +- board/amcc/ocotea/ocotea.c| 22 +- board/amcc/sequoia/sequoia.c | 28 +- board/amcc/taishan/showinfo.c | 112 ++-- board/amcc/taishan/taishan.c | 22 +- board/amcc/yosemite/yosemite.c| 32 +- board/amcc/yucca/yucca.c | 22 +- board/esd/common/cmd_loadpci.c|2 +- board/esd/du440/du440.c | 28 +- board/esd/pmc440/cmd_pmc440.c | 10 +- board/esd/pmc440/pmc440.c | 32 +- board/exbitgen/init.S |4 +- board/gdsys/gdppc440etx/gdppc440etx.c | 32 +- board/gdsys/intip/intip.c | 22 +- board/korat/korat.c | 28 +- board/lwmon5/lwmon5.c | 32 +- board/netstal/hcu5/hcu5.c | 28 +- board/pcs440ep/pcs440ep.c | 32 +- board/prodrive/alpr/alpr.c| 52 +- board/prodrive/p3p440/p3p440.c| 22 +- board/sandburst/common/ppc440gx_i2c.h |2 +- board/sandburst/common/sb_common.c| 22 +- board/xes/xpedite1000/xpedite1000.c | 24 +- common/cmd_reginfo.c | 158 + cpu/ppc4xx/4xx_pci.c | 48 +- cpu/ppc4xx/Makefile |4 + cpu/ppc4xx/cpu_init.c |4 +- cpu/ppc4xx/miiphy.c | 24 +- cpu/ppc4xx/reginfo.c | 369 + cpu/ppc4xx/speed.c|6 +- drivers/net/4xx_enet.c| 100 ++-- include/4xx_i2c.h |2 +- include/ppc405.h | 530 +++--- include/ppc440.h | 1401 +++-- include/ppc4xx.h | 36 +- include/ppc4xx_enet.h | 314 post/cpu/ppc4xx/ether.c | 50 +- 42 files changed, 2108 insertions(+), 1690 deletions(-) create mode 100644 cpu/ppc4xx/reginfo.c ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/4] ppc4xx: Overhaul for cmd reginfo
The command reginfo got an overhaul for the ppc4xx. It dumps all the relevant HW configuration registers (address, symbolic name, content). This allows to easily detect errors in *.h files and changes in the HW configuration. It is split in the following parts: - Cleanup some HW register names: Here you find all the changes in the include directory for new register names and adapting other ones to the names used by AMCC in their manuals, e.g. For 440EPx/GRPPC440EPx/GRX, Revision 1.15 â September 22, 2008 For PPC405GP Embedded Processor, Revision 1.02 â March 22, 2006 - Apply new HW register names Modify all existing *.c files to use the new register names. - Rework cmd reginfo Here the real work done to improve the reginfo command. - respect 80-chars per line in ppc*.h files After running checkstyle.pl on the three previous patches I noted that in the *.h files there were a lot of long lines. This patch solves this problem. I tested the changes on my PPC405GPr board HCU4 and PPC440EPx board HCU5. Only ran MAKEALL 4xx as I have no other cross-compilers installed. As I had not time to consult the documentation of all PPC440 variants (not have I boards to test it) the code in reginfo will probably dump less registers for none PPC440EPx variants. The DMA-registers are not dumped for the PPC440. I know that I could spend not only many hours but weeks to cleanup all the PPC4xx register naming conventions. I did not feel it my responsability to bring the lines in all 4xx board specific code to fit into 80 chars. But I think I will have soon a look at all the common 4xx files to bring them in shape as I would really like that a tool like checkstyle.pl from the Linux kernel only reports my errors. Niklaus Giger (4): ppc4xx: Cleanup some HW register names ppc_4xx: Apply new HW register names ppc4xx: Rework cmd reginfo ppc4xx: respect 80-chars per line in ppc*.h files board/amcc/bamboo/bamboo.c| 32 +- board/amcc/canyonlands/canyonlands.c | 22 +- board/amcc/ebony/ebony.c | 22 +- board/amcc/katmai/katmai.c| 22 +- board/amcc/luan/epld.h| 22 +- board/amcc/luan/luan.c| 22 +- board/amcc/ocotea/ocotea.c| 22 +- board/amcc/sequoia/sequoia.c | 28 +- board/amcc/taishan/showinfo.c | 112 ++-- board/amcc/taishan/taishan.c | 22 +- board/amcc/yosemite/yosemite.c| 32 +- board/amcc/yucca/yucca.c | 22 +- board/esd/common/cmd_loadpci.c|2 +- board/esd/du440/du440.c | 28 +- board/esd/pmc440/cmd_pmc440.c | 10 +- board/esd/pmc440/pmc440.c | 32 +- board/exbitgen/init.S |4 +- board/gdsys/gdppc440etx/gdppc440etx.c | 32 +- board/gdsys/intip/intip.c | 22 +- board/korat/korat.c | 28 +- board/lwmon5/lwmon5.c | 32 +- board/netstal/hcu5/hcu5.c | 28 +- board/pcs440ep/pcs440ep.c | 32 +- board/prodrive/alpr/alpr.c| 52 +- board/prodrive/p3p440/p3p440.c| 22 +- board/sandburst/common/ppc440gx_i2c.h |2 +- board/sandburst/common/sb_common.c| 22 +- board/xes/xpedite1000/xpedite1000.c | 24 +- common/cmd_reginfo.c | 158 + cpu/ppc4xx/4xx_pci.c | 48 +- cpu/ppc4xx/Makefile |4 + cpu/ppc4xx/cpu_init.c |4 +- cpu/ppc4xx/miiphy.c | 24 +- cpu/ppc4xx/reginfo.c | 369 + cpu/ppc4xx/speed.c|6 +- drivers/net/4xx_enet.c| 100 ++-- include/4xx_i2c.h |2 +- include/ppc405.h | 530 +++--- include/ppc440.h | 1401 +++-- include/ppc4xx.h | 36 +- include/ppc4xx_enet.h | 314 post/cpu/ppc4xx/ether.c | 50 +- 42 files changed, 2108 insertions(+), 1690 deletions(-) create mode 100644 cpu/ppc4xx/reginfo.c ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/4] ppc4xx: Cleanup some HW register names
Signed-off-by: Niklaus Giger niklaus.gi...@member.fsf.org --- include/4xx_i2c.h |2 +- include/ppc405.h |4 +- include/ppc440.h | 179 ++-- include/ppc4xx_enet.h | 220 + 4 files changed, 216 insertions(+), 189 deletions(-) diff --git a/include/4xx_i2c.h b/include/4xx_i2c.h index f0e772c..070657f 100644 --- a/include/4xx_i2c.h +++ b/include/4xx_i2c.h @@ -63,7 +63,7 @@ #define IIC_EXTSTS (I2C_REGISTERS_BASE_ADDRESS+IICEXTSTS) #define IIC_LSADR (I2C_REGISTERS_BASE_ADDRESS+IICLSADR) #define IIC_HSADR (I2C_REGISTERS_BASE_ADDRESS+IICHSADR) -#define IIC_CLKDIV (I2C_REGISTERS_BASE_ADDRESS+IICCLKDIV) +#define IIC_CLKDIV (I2C_REGISTERS_BASE_ADDRESS+IIC0_CLKDIV) #define IIC_INTRMSK(I2C_REGISTERS_BASE_ADDRESS+IICINTRMSK) #define IIC_XFRCNT (I2C_REGISTERS_BASE_ADDRESS+IICXFRCNT) #define IIC_XTCNTLSS (I2C_REGISTERS_BASE_ADDRESS+IICXTCNTLSS) diff --git a/include/ppc405.h b/include/ppc405.h index 5e56897..4c62249 100644 --- a/include/ppc405.h +++ b/include/ppc405.h @@ -578,7 +578,7 @@ #defineIICEXTSTS 0x09 #defineIICLSADR0x0A #defineIICHSADR0x0B -#defineIICCLKDIV 0x0C +#defineIIC0_CLKDIV 0x0C #defineIICINTRMSK 0x0D #defineIICXFRCNT 0x0E #defineIICXTCNTLSS 0x0F @@ -760,7 +760,7 @@ #define CPR0_PLLD 0x060 #define CPR0_CPUD 0x080 #define CPR0_PLBD 0x0a0 -#define CPR0_OPBD 0x0c0 +#define CPR0_OPBD0 0x0c0 #define CPR0_PERD 0x0e0 #define SDR0_PINSTP0x0040 diff --git a/include/ppc440.h b/include/ppc440.h index 378a9de..9299a71 100644 --- a/include/ppc440.h +++ b/include/ppc440.h @@ -60,9 +60,9 @@ /* values for clkcfga register - indirect addressing of these regs */ #define CPR0_PLLC 0x0040 #define CPR0_PLLD 0x0060 -#define CPR0_PRIMAD0x0080 -#define CPR0_PRIMBD0x00a0 -#define CPR0_OPBD 0x00c0 +#define CPR0_PRIMAD0 0x0080 +#define CPR0_PRIMBD0 0x00a0 +#define CPR0_OPBD0 0x00c0 #define CPR0_PERD 0x00e0 #define CPR0_MALD 0x0100 #define CPR0_SPCID 0x0120 @@ -100,7 +100,7 @@ #define SDR0_PFC1 0x4101 /* Pin Function 1 */ #define SDR0_MFR 0x4300 /* SDR0_MFR reg */ -#ifdef CONFIG_440GX +#if defined(CONFIG_440GX) #define SD0_AMP0x0240 #define SDR0_XPLLC 0x01c1 #define SDR0_XPLLD 0x01c2 @@ -1319,6 +1319,19 @@ #define SDR0_MFR_PKT_REJ_POL 0x0008 /* Packet Reject Polarity */ #endif + +#if defined(CONFIG_440EPX) +#define CPM0_ER0x00B0 +#define CPM1_ER0x00F0 +#define PLB4A0_ACR 0x0081 +#define PLB4A1_ACR 0x0089 +#define PLB3A0_ACR 0x0077 +#define OPB2PLB40_BCTRL0x0350 +#define P4P3BO0_CFG0x0026 +#define SPI0_MODE 0xEF600090 /* SPI Mode Regsgiter */ + +#endif + #if defined(CONFIG_440EPX) || defined(CONFIG_440GRX) #define SDR0_PFC1_EPS_ENCODE(n)unsigned long)(n))0x07)22) #define SDR0_PFC1_EPS_DECODE(n)unsigned long)(n))22)0x07) @@ -1385,6 +1398,12 @@ #define SDR0_SRST1_FPU 0x4000 /* Floating Point Unit */ #define SDR0_SRST1_KASU00x2000 /* Kasumi Engine */ +#define SDR0_EMAC0RXST 0x4301 /* */ +#define SDR0_EMAC0TXST 0x4302 /* */ +#define SDR0_CRYP0 0x4500 +#define SDR0_EBC0 0x0100 +#define SDR0_SDSTP20x4001 +#define SDR0_SDSTP30x4001 #elif defined(CONFIG_460EX) || defined(CONFIG_460GT) #define SDR0_SRST0 SDR0_SRST /* for compatability reasons */ @@ -1586,7 +1605,7 @@ #define IICEXTSTS 0x09 #define IICLSADR 0x0A #define IICHSADR 0x0B -#define IICCLKDIV 0x0C +#define IIC0_CLKDIV0x0C #define IICINTRMSK 0x0D #define IICXFRCNT 0x0E #define IICXTCNTLSS0x0F @@ -1595,10 +1614,10 @@ /*- | PCI Internal Registers et. al. (accessed via plb) +*/ -#define PCIX0_CFGADR (CONFIG_SYS_PCI_BASE + 0x0ec0) -#define PCIX0_CFGDATA (CONFIG_SYS_PCI_BASE + 0x0ec4) -#define PCIX0_CFGBASE (CONFIG_SYS_PCI_BASE + 0x0ec8) -#define PCIX0_IOBASE (CONFIG_SYS_PCI_BASE + 0x0800) +#define PCIL0_CFGADR (CONFIG_SYS_PCI_BASE + 0x0ec0) +#define PCIL0_CFGDATA (CONFIG_SYS_PCI_BASE + 0x0ec4) +#define PCIL0_CFGBASE (CONFIG_SYS_PCI_BASE + 0x0ec8) +#define PCIL0_IOBASE (CONFIG_SYS_PCI_BASE + 0x0800) #if defined(CONFIG_440EP) || defined(CONFIG_440GR) || \ defined(CONFIG_440EPX) ||
[U-Boot] [PATCH 3/4] ppc4xx: Rework cmd reginfo
The command reginfo got an overhaul for the ppc4xx. It dumps all the relevant HW configuration registers (address, symbolic name, content). This allows to easily detect errors in *.h files and changes in the HW configuration. Signed-off-by: Niklaus Giger niklaus.gi...@member.fsf.org --- common/cmd_reginfo.c | 158 +- cpu/ppc4xx/Makefile |4 + cpu/ppc4xx/reginfo.c | 369 ++ 3 files changed, 377 insertions(+), 154 deletions(-) create mode 100644 cpu/ppc4xx/reginfo.c diff --git a/common/cmd_reginfo.c b/common/cmd_reginfo.c index d0ebd0f..89fd9ec 100644 --- a/common/cmd_reginfo.c +++ b/common/cmd_reginfo.c @@ -25,8 +25,8 @@ #include command.h #if defined(CONFIG_8xx) #include mpc8xx.h -#elif defined (CONFIG_405GP) || defined(CONFIG_405EP) -#include asm/processor.h +#elif defined (CONFIG_4xx) +extern void ppc4xx_reginfo(void); #elif defined (CONFIG_5xx) #include mpc5xx.h #elif defined (CONFIG_MPC5200) @@ -90,158 +90,8 @@ int do_reginfo (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[]) * May be some CPM info here? */ -#elif defined (CONFIG_405GP) - printf (\n405GP registers; MSR=%08x\n,mfmsr()); - printf (\nUniversal Interrupt Controller Regs\n - UIC0SRUIC0ERUIC0CRUIC0PRUIC0TRUIC0MSR UIC0VR UIC0VCR - \n - %08x %08x %08x %08x %08x %08x %08x %08x\n, - mfdcr(UIC0SR), - mfdcr(UIC0ER), - mfdcr(UIC0CR), - mfdcr(UIC0PR), - mfdcr(UIC0TR), - mfdcr(UIC0MSR), - mfdcr(UIC0VR), - mfdcr(UIC0VCR)); - - puts (\nMemory (SDRAM) Configuration\n - besrabesrsa besrbbesrsb bear mcopt1 rtr pmit\n); - - mtdcr(SDRAM0_CFGADDR,SDRAM0_BESR0); printf (%08x , mfdcr(SDRAM0_CFGDATA)); - mtdcr(SDRAM0_CFGADDR,SDRAM0_BESRS0);printf (%08x , mfdcr(SDRAM0_CFGDATA)); - mtdcr(SDRAM0_CFGADDR,SDRAM0_BESR1); printf (%08x , mfdcr(SDRAM0_CFGDATA)); - mtdcr(SDRAM0_CFGADDR,SDRAM0_BESRS1);printf (%08x , mfdcr(SDRAM0_CFGDATA)); - mtdcr(SDRAM0_CFGADDR,SDRAM0_BEAR); printf (%08x , mfdcr(SDRAM0_CFGDATA)); - mtdcr(SDRAM0_CFGADDR,SDRAM0_CFG); printf (%08x , mfdcr(SDRAM0_CFGDATA)); - mtdcr(SDRAM0_CFGADDR,SDRAM0_RTR); printf (%08x , mfdcr(SDRAM0_CFGDATA)); - mtdcr(SDRAM0_CFGADDR,SDRAM0_PMIT); printf (%08x , mfdcr(SDRAM0_CFGDATA)); - - puts (\n - mb0cfmb1cfmb2cfmb3cfsdtr1ecccfeccerr\n); - mtdcr(SDRAM0_CFGADDR,SDRAM0_B0CR); printf (%08x , mfdcr(SDRAM0_CFGDATA)); - mtdcr(SDRAM0_CFGADDR,SDRAM0_B1CR); printf (%08x , mfdcr(SDRAM0_CFGDATA)); - mtdcr(SDRAM0_CFGADDR,SDRAM0_B2CR); printf (%08x , mfdcr(SDRAM0_CFGDATA)); - mtdcr(SDRAM0_CFGADDR,SDRAM0_B3CR); printf (%08x , mfdcr(SDRAM0_CFGDATA)); - mtdcr(SDRAM0_CFGADDR,SDRAM0_TR);printf (%08x , mfdcr(SDRAM0_CFGDATA)); - mtdcr(SDRAM0_CFGADDR,SDRAM0_ECCCFG);printf (%08x , mfdcr(SDRAM0_CFGDATA)); - mtdcr(SDRAM0_CFGADDR,SDRAM0_ECCESR);printf (%08x , mfdcr(SDRAM0_CFGDATA)); - - printf (\n\n - DMA Channels\n - DMASRDMASGC DMAADR\n - %08x %08x %08x\n - dmacr_0 dmact_0 dmada_0 dmasa_0 dmasb_0\n - %08x %08x %08x %08x %08x\n - dmacr_1 dmact_1 dmada_1 dmasa_1 dmasb_1\n - %08x %08x %08x %08x %08x\n, - mfdcr(DMASR), mfdcr(DMASGC),mfdcr(DMAADR), - mfdcr(DMACR0), mfdcr(DMACT0),mfdcr(DMADA0), mfdcr(DMASA0), mfdcr(DMASB0), - mfdcr(DMACR1), mfdcr(DMACT1),mfdcr(DMADA1), mfdcr(DMASA1), mfdcr(DMASB1)); - - printf ( - dmacr_2 dmact_2 dmada_2 dmasa_2 dmasb_2\n %08x %08x %08x %08x %08x\n - dmacr_3 dmact_3 dmada_3 dmasa_3 dmasb_3\n %08x %08x %08x %08x %08x\n, - mfdcr(DMACR2), mfdcr(DMACT2),mfdcr(DMADA2), mfdcr(DMASA2), mfdcr(DMASB2), - mfdcr(DMACR3), mfdcr(DMACT3),mfdcr(DMADA3), mfdcr(DMASA3), mfdcr(DMASB3) ); - - puts (\n - External Bus\n - PBEARPBESR0 PBESR1 EBC0_CFG\n); - mtdcr(EBC0_CFGADDR,PBEAR); printf (%08x , mfdcr(EBC0_CFGDATA)); - mtdcr(EBC0_CFGADDR,PBESR0); printf (%08x , mfdcr(EBC0_CFGDATA)); - mtdcr(EBC0_CFGADDR,PBESR1); printf (%08x , mfdcr(EBC0_CFGDATA)); - mtdcr(EBC0_CFGADDR,EBC0_CFG); printf (%08x , mfdcr(EBC0_CFGDATA)); - - puts (\n - PB0CRPB0APPB1CRPB1APPB2CRPB2APPB3CR PB3AP\n); - mtdcr(EBC0_CFGADDR,PB0CR); printf (%08x , mfdcr(EBC0_CFGDATA)); - mtdcr(EBC0_CFGADDR,PB0AP); printf (%08x , mfdcr(EBC0_CFGDATA)); - mtdcr(EBC0_CFGADDR,PB1CR); printf (%08x , mfdcr(EBC0_CFGDATA)); - mtdcr(EBC0_CFGADDR,PB1AP); printf (%08x , mfdcr(EBC0_CFGDATA)); - mtdcr(EBC0_CFGADDR,PB2CR); printf (%08x , mfdcr(EBC0_CFGDATA)); -
Re: [U-Boot] [PATCH] CFI Driver: Reset watchdog timer after each flash operation
On Friday 02 October 2009 08:30:51 Wolfgang Denk wrote: Ingo van Lil wrote: The CFI driver does not reset the device's watchdog, so long-running flash operations will cause the watchdog timer to expire. A comment in flash_status_check() suggests that udelay() is expected to reset the watchdog, but I can't find any architecture where it does. Please have a closer look, then. On PowerPC, udelay() [lib_ppc/time.c] calls wait_ticks(), which in turn [lib_ppc/ticks.S] calls WATCHDOG_RESET If this is missing in other architectures, it should be fixed at the root cause, i. e. in udelay() or in the respective support routines. Blackfin is missing it as well as i really had no idea it was supposed to be there. certainly no doc states this requirement. perhaps it'd make sense to break apart the common stuff to a common udelay() that does things like call the watchdog and then call the implementation __udelay(). there should be at least a doc/README.arch that includes these kind of details ... -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] CFI Driver: Reset watchdog timer after each flash operation
Dear Mike Frysinger, In message 200910021431.23079.vap...@gentoo.org you wrote: Blackfin is missing it as well as i really had no idea it was supposed to be there. certainly no doc states this requirement. perhaps it'd make sense to break apart the common stuff to a common udelay() that does things like call the watchdog and then call the implementation __udelay(). there should be at least a doc/README.arch that includes these kind of details ... Agreed - we should start and collect such documentation about internal data structures, APIs, expectations of the code and the like to the wiki. 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 heart is not a logical organ. -- Dr. Janet Wallace, The Deadly Years, stardate 3479.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] standalone: Increment XF_VERSION to 6
Signed-off-by: Peter Tyser pty...@xes-inc.com
---
This should be squashed with the top-most commit in the
reloc branch.
Ideally we could fold
[PATCH/RFC] arm/microblaze/nios/nios2/sh: Remove relocation fixups
into the reloc branch too so we don't have to increment XF_VERSION
again in the next release. I have no way of testing these
arches though
include/exports.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/exports.h b/include/exports.h
index 16ea03a..2e8fd8b 100644
--- a/include/exports.h
+++ b/include/exports.h
@@ -47,7 +47,7 @@ enum {
XF_MAX
};
-#define XF_VERSION 5
+#define XF_VERSION 6
#if defined(CONFIG_I386)
extern gd_t *global_data;
--
1.6.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] CFI Driver: Reset watchdog timer after each flash operation
Mike Frysinger wrote: On Friday 02 October 2009 08:30:51 Wolfgang Denk wrote: Ingo van Lil wrote: The CFI driver does not reset the device's watchdog, so long-running flash operations will cause the watchdog timer to expire. A comment in flash_status_check() suggests that udelay() is expected to reset the watchdog, but I can't find any architecture where it does. Please have a closer look, then. On PowerPC, udelay() [lib_ppc/time.c] calls wait_ticks(), which in turn [lib_ppc/ticks.S] calls WATCHDOG_RESET If this is missing in other architectures, it should be fixed at the root cause, i. e. in udelay() or in the respective support routines. Blackfin is missing it as well as i really had no idea it was supposed to be there. certainly no doc states this requirement. perhaps it'd make sense to break apart the common stuff to a common udelay() that does things like call the watchdog and then call the implementation __udelay(). there should be at least a doc/README.arch that includes these kind of details ... -mike At this point it might be appropriate to ask if including such a reset in udelay() is a good idea. The way it is, no infinite loop in u-boot that contains a udelay() will ever allow the watchdog to time out. That restriction is somewhat non-obvious. I would argue that there are basically two classes of commands in u-boot, those that should execute so fast that there is no way the watchdog should be triggered, and commands that may take a long time during which the watchdog may erroneously be triggered if there is no provision made to reset it. In the second case, the resetting of the watchdog must be placed where measurable progress towards command completion is being made, i.e. there is a certainty that we are getting closer to a command complete. Just because the program invokes udelay, there is no assurance that measurable progress is being made. The udelay may be part of a process that will never complete. Therefore, having a watchdog reset in udelay seems like a less than optimal idea in general. Maybe now would be a good time to look at removing it? Bill Campbell ___ 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] Preserving frame buffer memory between uboot and Linux
Hi, We have a situation when we want to display an image towards the end of Uboot's execution, before we boot Linux. I have that already. However, my issue is that while Linux boots it mallocs a new frame buffer and reinitializes the LCD controller with a new memory address. At the moment in Uboot the frame buffer is at 0x23F39000. In Linux I see it being mapped to 0x2398. Is there a way to force Linux to use the already-allocated frame buffer memory so the image doesn't go away? I am running on an Atmel AT91SAM9RL with Uboot 2008.10 and 2.6.28 Linux. Thanks in advance, Steve -- View this message in context: http://www.nabble.com/Preserving-frame-buffer-memory-between-uboot-and-Linux-tp25722060p25722060.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] Freescale MXC: NAND UnCorrectable RS-ECC Error
Thanks Magnus! Which MXC platform are you using and does it support 4K page size? And does mxc_nand.c support 4K page size? I am using mx35 and the NAND flash controller therein supports 4K page operations as evident from the manual. from the code in mxc_nand.c it looks like it checks for whether or not its a 4K page NAND and assigns a different OOB layout based on that. I am not sure as i havent gathered a full understanding of the ECC/OOB mechanism. How do we define the functions owned by the mxc_nand.c(board specific driver) and the generic driver nand_base.c or is it a layered design? Can you please elaborate on it? -Alfred. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH-ARM 1/4, v2] Clean-up of cpu_arm920t and cpu_arm920t_s3c24x0 code
Minkyu Kang wrote: Dear kevin Morfitt sorry for blank message 2009/9/30 Minkyu Kang proms...@gmail.com: Dear Kevin Morfitt 2009/9/26 kevin.morf...@fearnside-systems.co.uk kevin.morf...@fearnside-systems.co.uk: Changes since v1: - re-formatted patch to remove line wrapping Note that patch 2/4 of this series has not changed. This patch re-formats the code in cpu/arm920t and cpu/arm920t/23c24x0 in preparation for changes to add support for the Embest SBC2440-II Board. The changes are as follows: - re-indent the code using Lindent - make sure register layouts are defined using a C struct - replace the upper-case typedef'ed C struct names with lower case non-typedef'ed ones - make sure registers are accessed using the proper accessor functions - run checkpatch.pl and fix any error reports Note that usb_ohci.c still has two lines that exceed 80 characters. This is because the statements on those lines lose readability when wrapped - the Linux coding style guidelines allow for this. It assumes the following patch has been applied first: - [U-Boot][PATCH-ARM] CONFIG_SYS_HZ fix for ARM902T S3C24X0 Boards, 05/09/2009 Tested on an Embest SBC2440-II Board with local u-boot patches as I don't have any s3c2400 or s3c2410 boards but need this patch applying before I can submit patches for the SBC2440-II Board. Also, ran MAKEALL for all ARM9 targets and no new warnings or errors were found. Signed-off-by: Kevin Morfitt kevin.morf...@fearnside-systems.co.uk --- cpu/arm920t/s3c24x0/interrupts.c |2 +- cpu/arm920t/s3c24x0/speed.c | 42 +- cpu/arm920t/s3c24x0/timer.c | 74 ++- cpu/arm920t/s3c24x0/usb.c| 30 +- cpu/arm920t/s3c24x0/usb_ohci.c | 1268 -- cpu/arm920t/s3c24x0/usb_ohci.h | 187 +++--- cpu/arm920t/start.S | 63 +- 7 files changed, 873 insertions(+), 793 deletions(-) I didn't see all of your patch. Here are links to the patches and notes on their states: - [U-boot] [PATCH-ARM] CONFIG_SYS_HZ change for cpu/arm920t/s3c24x0 boards: http://lists.denx.de/pipermail/u-boot/2009-September/thread.html, JP said it looked OK but needed testing, then it was tested by Wolfgang - [U-Boot] [PATCH-ARM 1/4, v2] Clean-up of cpu/arm920t and cpu/arm920t/s3c24x0 code (this patch): one comment so far (your own) - [U-Boot] [PATCH-ARM 2/4] Clean-up of s3c24x0 header files: http://lists.denx.de/pipermail/u-boot/2009-September/060111.html, no comments as yet - [U-Boot] [PATCH-ARM 3/4, v2] Clean-up of s3c24x0 drivers excluding nand driver, http://lists.denx.de/pipermail/u-boot/2009-September/061583.html, one comment by Gaye Abdoulaye Walsimou, fixed in v2 - [U-Boot] [PATCH-ARM 4/4, v2] Clean-up of s3c24x0 nand driver, http://lists.denx.de/pipermail/u-boot/2009-September/061584.html, v1 was Acked by Scott here - http://lists.denx.de/pipermail/u-boot/2009-September/060580.html But there are remained more works for cleaning My aim is to clean up just the s3c24x0 common code so I can later add support for the Embest SBC2440-II Board. I can see that the rest of the arm920t code also needs cleaning but this would be a much bigger job and could be done later - I'd rather limit these patches to s3c24x0 code. please use lower case name at C structure's members and functions I think I have changed all structure names to lower case in the s3c24x0 code. I also think I've changed all function names to lower case except where the change would affect too many other areas - for example, if I change get_HCLK() to get_hclk() in cpu/arm920t/s3c24x0/speed.c I'd also need to change the same in include/common.h, cpu/lh7a40x, arm920t/imx and arm1176/s3c64xx and all functions that call get_HCLK() throughout u-boot. Again, this does need doing but could be done later. Regards Kevin Thanks Minkyu Kang ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] problem detecting CFI
I can fix this problem not but I really don't understand how the problem happens in the first place. I found gp got changed in relocate_code in file start.S. In relocate_code function, the $gp is adjusted to point to the new location, but somehow before program jumps to the relocated place, $gp was changed. But I don't know where it is changed. So I used t8 register to save the adjusted gp, and put it back before it jump to DRAM. But I don't know why $gp was changed in the between. Can someone give me some idea? I did not touch any thing else in this file. /* * Fix $gp: * * New $gp = (Old $gp - CONFIG_SYS_MONITOR_BASE) + Destination Address */ movet6, gp sub gp, CONFIG_SYS_MONITOR_BASE add gp, a2 /* gp now adjusted */ movet8, gp /* add here === save gp */ ... /* Jump to where we've relocated ourselves. */ movegp, t8/* add here === copy gp back */ addit0, s2, in_ram - _start jr t0 nop On Thu, 01 Oct 2009 18:25 -0500, w...@fastmail.fm wrote: I just found something interesting - In my previous email I thought the CFI detection was running from DRAM, but that assumption seems to be wrong. Previously I though it was running from DRAM because I traced the execution using BDI into mips/startcpu/mips/start.S relocate_code, it runs to the place where it relocates itself. To be exact, here - addi t0, s2, in_ram - start jr t0 nop I checked and found the pc register changed to pointing to a SDRAM location, so relocation seems to be fine. I also load the symbol-file to the DRAM location at that point. But afterwards if I set breakpoint to board_init_r, the breakpoint is not triggered. Then I realized if I keep using the same symbol-file, the breakpoint at board_init_r can be triggered, and at that point, I can see the PC is still pointing to the flash. I don't understand how can the code, which has been relocated to SDRAM at one point, suddenly going back to run in the flash when it calls board_init_r. Can someone help me? Thanks. On Thu, 01 Oct 2009 16:47 -0500, w...@fastmail.fm wrote: I have a working u-boot 2008.10 on a mips 32 board and am trying to port it over to u-boot 2009.06. So I used buildroot 2009.08 to build the tool chain for my mips32 board as well as u-boot2009.06. I also copied the previous u-boot initialization code to initialize timer, serial port, ram and etc from u-boot 2008.10 to 2009.06. Right now the problem is the new u-boot 2009.06 does not detect cfi of the flash. I am pretty sure u-boot is running from SDRAM when the problem happens because the address is in the range of SDRAM. Please let me know if you have any suggestion - I am running out of ideas. I am attaching the printout from both the working u-boot 2008.10 and u-boot 2009.06 below. Thanks a lot. U-Boot 2009.06 (Sep 30 2009 - 18:41:26) Reset Cause: Hardware Reset DRAM: 64 MB Top of RAM usable for U- Boot at: 9800 Reserving 139k for U-Boot at: 97fdc000 Reserving 4352k for malloc() at: 97b9c000 Reserving 36 Bytes for Board Info at: 97b9bfdc Reserving 36 Bytes for Global Data at: 97b9bfb8 Reserving 128k for boot params() at: 97b7bfb8 Stack Pointer at: 97b7bf98 Now running in RAM - U-Boot at: 97fdc000 flash detect cfi not found flash detect cfi not found U-Boot 2008.10 (Sep 30 2009 - 11:37:03) Reset Cause: Hardware Reset DRAM: 64 MB Top of RAM usable for U- Boot at: 9800 Reserving 736k for U-Boot at: 97f44000 Reserving 4352k for malloc() at: 97b04000 Reserving 44 Bytes for Board Info at: 97b03fd4 Reserving 36 Bytes for Global Data at: 97b03fb0 Reserving 128k for boot params() at: 97ae3fb0 Stack Pointer at: 97ae3f98 Now running in RAM - U-Boot at: 97f44000 flash detect cfi fwc addr b000 cmd f0 f0 8bit x 8 bit fwc addr b000 cmd ff ff 8bit x 8 bit fwc addr b055 cmd 98 98 8bit x 8 bit is= cmd 51(Q) addr b010 is= 4f 51 fwc addr b555 cmd 98 98 8bit x 8 bit is= cmd 51(Q) addr b010 is= 4f 51 fwc addr b000 cmd f0 f0f0 16bit x 8 bit fwc addr b000 cmd ff 16bit x 8 bit fwc addr b0aa cmd 98 9898 16bit x 8 bit is= cmd 51(Q) addr b020 is= 5151 5151 is= cmd 52(R) addr b022 is= 5252 5252 is= cmd 59(Y) addr b024 is= 5959 5959 device interface is 2 found port 2 chip 1 port 16 bits chip 8 bits ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] CFI Driver: Reset watchdog timer after each flash operation
Dear J. William Campbell, In message 4ac660e3.4010...@comcast.net you wrote: At this point it might be appropriate to ask if including such a reset in udelay() is a good idea. The way it is, no infinite loop in u-boot that contains a udelay() will ever allow the watchdog to time out. That Indeed. We do not have any watchdog preotection for U-Boot itself. U-Boot just makes sure to allow booting an OS with the watchdog activated. Just because the program invokes udelay, there is no assurance that measurable progress is being made. The udelay may be part of a process that will never complete. Therefore, having a watchdog reset in udelay seems like a less than optimal idea in general. Maybe now would be a good time to look at removing it? There are other places which have similar issues. For example, you will probably find that most serial drivers (at least those being used on systems with active watchdogs) will have WATCHDOG_RESET() calls in their getc() implementations - which is needed to trigger the WD while the board is in interactive mode, waiting for input. WD support in U-Boot is just good enough to bridge the time until the OS starts to do the right thing. We do not trry to WD-protect U-Boot itself yet. Implementing such protection would definitely be a good thing to have, but non-trivial effort, too. It would require much more changes than removing the trigger from the udelay() code. Please feel free to submit patches... 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 door is what a dog is perpetually on the wrong side of. - Ogden Nash ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Preserving frame buffer memory between uboot and Linux
Dear Steven Zedeck, In message 25722060.p...@talk.nabble.com you wrote: We have a situation when we want to display an image towards the end of Uboot's execution, before we boot Linux. I have that already. However, my issue is that while Linux boots it mallocs a new frame buffer and reinitializes the LCD controller with a new memory address. At the moment in Uboot the frame buffer is at 0x23F39000. In Linux I see it being mapped to 0x2398. Is there a way to force Linux to use the already-allocated frame buffer memory so the image doesn't go away? In mainline: not, or not yet at least. In our linux-2.6-denx repo you can find these commits: commit 01baab26e52bc66cb1781ab970fba932b592f2ee Author: Anatolij Gustschin ag...@denx.de Date: Wed May 28 23:45:21 2008 +0200 Fix to enable console cursor drawing capability if CONFIG_FB_PRE_INIT_FB defined Background: By defining the CONFIG_FB_PRE_INIT_FB option in the Linux kernel configuration the framebuffer state set by the boot loader before booting the Linux kernel will be preserved in order to avoid display flicker and splash screen destruction. To ensure this, this option also disabled framebuffer console cursor drawing capability entirely. This was pretty invasive restriction and didn't allow using console cursor drawing later in applications which need the visible cursor. Now this patch is introduced to get rid of this restriction. If CONFIG_FB_PRE_INIT_FB is defined in the Linux kernel configuration, the framebuffer state will still be preserved (as set by the boot loader) and also framebuffer console cursor drawing will be disabled. If an application needs visible cursor, it should enable cursor drawing by writing escape sequence ESC[?25h to the console device. E.g. echo -e \33[?25h /dev/tty0 Signed-off-by: Anatolij Gustschin ag...@denx.de ... commit 6c3b5cdbc84b43190996124debc8fb29c9bf90ed Author: Anatolij Gustschin ag...@denx.de Date: Tue Jan 15 00:28:23 2008 +0100 Add CONFIG_FB_PRE_INIT_FB option CONFIG_FB_PRE_INIT_FB option allows to inherit display controller configuration and framebuffer contents from the state set by the bootloader. Signed-off-by: Anatolij Gustschin ag...@denx.de They do exactly what you are looking for. I remember that someone tried to clean this up and poush it into mainline, but IIRC this attempt failed because the PTB considered this an exotic requirement from those insane embedded folks which was not needed on any real systems. I am running on an Atmel AT91SAM9RL with Uboot 2008.10 and 2.6.28 Linux. Hope this helps. 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 Four thousand throats may be cut in one night by a running man. -- Klingon Soldier, Day of the Dove, stardate unknown ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mem_mtest: fix error reporting, allow escape with ^C
The basic memtest function tries to watch for ^C after each
pattern pass as an escape mechanism, but if things are horribly
wrong, we'll be stuck in an inner loop flooding the console with
error messages and never check for ^C. To make matters worse,
if the user waits for all the error messages to complete, we
then incorrectly report the test passed without errors.
Adding a check for ^C after any error is printed will give
the end user an escape mechanism from a console flood without
slowing down the overall test speed on a slow processor.
Also, the more extensive memtest quit after just a single error,
which is inconsistent with the normal memtest, and not useful if
if you are doing dynamic environmental impact testing, such as
heating/cooling etc.
Both tests now track the error count and report it properly
at test completion.
Signed-off-by: Paul Gortmaker paul.gortma...@windriver.com
---
Changes: fixed return values since prev. version.
common/cmd_mem.c | 58 -
1 files changed, 44 insertions(+), 14 deletions(-)
diff --git a/common/cmd_mem.c b/common/cmd_mem.c
index 9850800..a34b342 100644
--- a/common/cmd_mem.c
+++ b/common/cmd_mem.c
@@ -631,7 +631,7 @@ int do_mem_mtest (cmd_tbl_t *cmdtp, int flag, int argc,
char *argv[])
vu_long *addr, *start, *end;
ulong val;
ulong readback;
- int rcode = 0;
+ ulong errs = 0;
int iterations = 1;
int iteration_limit;
@@ -698,9 +698,9 @@ int do_mem_mtest (cmd_tbl_t *cmdtp, int flag, int argc,
char *argv[])
if (iteration_limit iterations iteration_limit) {
- printf(Tested %d iteration(s) without errors.\n,
- iterations-1);
- return 0;
+ printf(Tested %d iteration(s) with %lu errors.\n,
+ iterations-1, errs);
+ return errs != 0;
}
printf(Iteration: %6d\r, iterations);
@@ -732,9 +732,14 @@ int do_mem_mtest (cmd_tbl_t *cmdtp, int flag, int argc,
char *argv[])
*dummy = ~val; /* clear the test data off of the bus */
readback = *addr;
if(readback != val) {
-printf (FAILURE (data line):
+ printf (FAILURE (data line):
expected %08lx, actual %08lx\n,
val, readback);
+ errs++;
+ if (ctrlc()) {
+ putc ('\n');
+ return 1;
+ }
}
*addr = ~val;
*dummy = val;
@@ -743,6 +748,11 @@ int do_mem_mtest (cmd_tbl_t *cmdtp, int flag, int argc,
char *argv[])
printf (FAILURE (data line):
Is %08lx, should be %08lx\n,
readback, ~val);
+ errs++;
+ if (ctrlc()) {
+ putc ('\n');
+ return 1;
+ }
}
}
}
@@ -808,7 +818,11 @@ int do_mem_mtest (cmd_tbl_t *cmdtp, int flag, int argc,
char *argv[])
printf (\nFAILURE: Address bit stuck high @ 0x%.8lx:
expected 0x%.8lx, actual 0x%.8lx\n,
(ulong)start[offset], pattern, temp);
- return 1;
+ errs++;
+ if (ctrlc()) {
+ putc ('\n');
+ return 1;
+ }
}
}
start[test_offset] = pattern;
@@ -826,7 +840,11 @@ int do_mem_mtest (cmd_tbl_t *cmdtp, int flag, int argc,
char *argv[])
printf (\nFAILURE: Address bit stuck low or
shorted @
0x%.8lx: expected 0x%.8lx, actual 0x%.8lx\n,
(ulong)start[offset], pattern, temp);
- return 1;
+ errs++;
+ if (ctrlc()) {
+ putc ('\n');
+ return 1;
+ }
}
}
start[test_offset] = pattern;
@@ -864,7 +882,11 @@ int do_mem_mtest (cmd_tbl_t *cmdtp, int flag, int argc,
char *argv[])
printf (\nFAILURE (read/write) @ 0x%.8lx:
expected 0x%.8lx, actual 0x%.8lx)\n,
(ulong)start[offset], pattern, temp);
- return 1;
+
[U-Boot] [PATCH] mpc86xx: delete unused MPC86xx_DDR_SDRAM_CLK_CNTL define
This is an orphaned legacy leftover that is just polluting the config file namespace. Signed-off-by: Paul Gortmaker paul.gortma...@windriver.com --- include/configs/MPC8610HPCD.h |2 -- include/configs/MPC8641HPCN.h |2 -- include/configs/sbc8641d.h|2 -- 3 files changed, 0 insertions(+), 6 deletions(-) diff --git a/include/configs/MPC8610HPCD.h b/include/configs/MPC8610HPCD.h index 7619328..7cb4ccd 100644 --- a/include/configs/MPC8610HPCD.h +++ b/include/configs/MPC8610HPCD.h @@ -102,8 +102,6 @@ #define CONFIG_SYS_MAX_DDR_BAT_SIZE0x8000 /* BAT mapping size */ #define CONFIG_VERY_BIG_RAM -#define MPC86xx_DDR_SDRAM_CLK_CNTL - #define CONFIG_NUM_DDR_CONTROLLERS 1 #define CONFIG_DIMM_SLOTS_PER_CTLR 1 #define CONFIG_CHIP_SELECTS_PER_CTRL (2 * CONFIG_DIMM_SLOTS_PER_CTLR) diff --git a/include/configs/MPC8641HPCN.h b/include/configs/MPC8641HPCN.h index b0ae25c..a46f7c8 100644 --- a/include/configs/MPC8641HPCN.h +++ b/include/configs/MPC8641HPCN.h @@ -141,8 +141,6 @@ extern unsigned long get_board_sys_clk(unsigned long dummy); #define CONFIG_SYS_MAX_DDR_BAT_SIZE0x8000 /* BAT mapping size */ #define CONFIG_VERY_BIG_RAM -#define MPC86xx_DDR_SDRAM_CLK_CNTL - #define CONFIG_NUM_DDR_CONTROLLERS 2 #define CONFIG_DIMM_SLOTS_PER_CTLR 2 #define CONFIG_CHIP_SELECTS_PER_CTRL (2 * CONFIG_DIMM_SLOTS_PER_CTLR) diff --git a/include/configs/sbc8641d.h b/include/configs/sbc8641d.h index 2865df5..682d241 100644 --- a/include/configs/sbc8641d.h +++ b/include/configs/sbc8641d.h @@ -121,8 +121,6 @@ #define CONFIG_SYS_MAX_DDR_BAT_SIZE0x8000 /* BAT mapping size */ #define CONFIG_VERY_BIG_RAM -#define MPC86xx_DDR_SDRAM_CLK_CNTL - #define CONFIG_NUM_DDR_CONTROLLERS 2 #define CONFIG_DIMM_SLOTS_PER_CTLR 2 #define CONFIG_CHIP_SELECTS_PER_CTRL (2 * CONFIG_DIMM_SLOTS_PER_CTLR) -- 1.6.5.rc1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mpc83xx: cosmetic comment update relating to SPD EEPROM
commit 6d0f6bcf337c5261c08fabe12982178c2c489d76 did the big rename of CFG_ macros to CONFIG_SYS macros. But it missed a couple of instances within comments. Signed-off-by: Paul Gortmaker paul.gortma...@windriver.com --- include/configs/sbc8349.h |2 +- include/configs/vme8349.h |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/include/configs/sbc8349.h b/include/configs/sbc8349.h index bf7cf82..4dea27d 100644 --- a/include/configs/sbc8349.h +++ b/include/configs/sbc8349.h @@ -304,7 +304,7 @@ #define CONFIG_SYS_I2C1_OFFSET 0x3000 #define CONFIG_SYS_I2C2_OFFSET 0x3100 #define CONFIG_SYS_I2C_OFFSET CONFIG_SYS_I2C2_OFFSET -/* could also use CONFIG_I2C_MULTI_BUS and CONFIG_SPD_BUS_NUM... */ +/* could also use CONFIG_I2C_MULTI_BUS and CONFIG_SYS_SPD_BUS_NUM... */ /* TSEC */ #define CONFIG_SYS_TSEC1_OFFSET 0x24000 diff --git a/include/configs/vme8349.h b/include/configs/vme8349.h index d0690fe..f9db73b 100644 --- a/include/configs/vme8349.h +++ b/include/configs/vme8349.h @@ -224,7 +224,7 @@ #define CONFIG_SYS_I2C1_OFFSET 0x3000 #define CONFIG_SYS_I2C2_OFFSET 0x3100 #define CONFIG_SYS_I2C_OFFSET CONFIG_SYS_I2C1_OFFSET -/* could also use CONFIG_I2C_MULTI_BUS and CONFIG_SPD_BUS_NUM... */ +/* could also use CONFIG_I2C_MULTI_BUS and CONFIG_SYS_SPD_BUS_NUM... */ #define CONFIG_SYS_I2C_8574_ADDR2 0x20/* I2C1, PCF8574 */ -- 1.6.5.rc1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] part_dos: check status flags of partitions
ping?
On Mon, Sep 28, 2009 at 12:04:00PM +0200, Daniel Mack wrote:
The current fatload code has a problem together with the way the DOS
partition parser is implemented.
This hit me when I tried to load a file from a USB stick which had no
partition table but a FAT16 directly written to the first sector.
With such an environment, get_partition_info_extended() still finds a
valid partition at the first sector since the 0x55aa magic is valid for
both the MBR and the FAT boot sector.
As a result, part_offset in fs/fat/fat.c is then set to some ridiculous
value and the code searching for the directory entry gets lots in an
endless loop.
The fix is quite simple though - we just need to check the status field
of the partitions more stricly. According to the specs, it may only
contain 0x00 and 0x80. If get_partition_info() fails for this case, the
fatload code falls back to the assumption that there is no partition
table and does the right thing then.
Please consider applying the following patch.
Daniel
From 381a85bf04adc228cc70e8fa7af899a6dbf07e42 Mon Sep 17 00:00:00 2001
From: Daniel Mack dan...@caiaq.de
Date: Mon, 28 Sep 2009 11:40:38 +0200
Subject: [PATCH] part_dos: check status flags of partitions
Only read partitions which have 0x00 or 0x80 set in their status field.
All others are invalid.
Signed-off-by: Daniel Mack dan...@caiaq.de
---
disk/part_dos.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/disk/part_dos.c b/disk/part_dos.c
index 93bf3dd..e32d58e 100644
--- a/disk/part_dos.c
+++ b/disk/part_dos.c
@@ -188,7 +188,8 @@ static int get_partition_info_extended (block_dev_desc_t
*dev_desc, int ext_part
* fdisk does not show the extended partitions that
* are not in the MBR
*/
- if ((pt-sys_ind != 0)
+ if (((pt-boot_ind ~0x80) == 0)
+ (pt-sys_ind != 0)
(part_num == which_part)
(is_extended(pt-sys_ind) == 0)) {
info-blksz = 512;
--
1.6.3.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
