[U-Boot] No nandflash found if CONFIG_CMD_UBI is enabled.
Hi!
I'm trying to enable the UBI-support in U-Boot (later intending to
also enable the UBIFS-support). This is on a AT91SAM9260-based system.
I've verified the same behaviour using both the
at91sam9260ek_nandflash_config and a forward-ported patch for the
Olimex sam9_l9260 board. Currently I'm concentrating on the
at91sam9260ek_nandflash_config, as this one is in the U-Boot
repository.
However, once I enable the UBI-support, the nand-flash chip is not detected...
I've tried to trace the problem, and I've found that it is
timer-related. It seems that once I enable CONFIG_CMD_UBI, the timer
does not work (the debug-printf in the get_ticks()-function in the
supplied patch is not printing). If I comment out CONFIG_CMD_UBI,
U-Boot continously prints stuff like:
Debug: timestamp=6
Debug: timestamp=10215
Debug: timestamp=21556
which is expected.
I'm compiling by running:
make clean
make at91sam9260ek_nandflash_config
make
and then flashing u-boot.bin to the board.
The supplied patch works, unless the '#define CONFIG_CMD_UBI 1'
is uncommented, in which case the get_ticks function in
cpu/arm926ejs/at91/timer.c never seems to be called. I've sofar been
unable to understand why.
The U-Boot versions used are from the u-boot.git and u-boot-at91.git
repositories, as check out yesterday and today:
U-Boot, with the latest commit 5520ab1f7685721314dcfb7cdcc7c15e6571473f
U-Boot-at91, with the latest commit f8ddcd58221cab63dd25c2324dd2032487f748b1
I've also verifed the same behaviour with both the CodeSourcery's
toolchain (Sourcery G++ Lite 2008q1-126, gcc 4.2.3), as well as my own
build through buildroot (gcc 4.3.3).
Regards,
Anders
The modifications I've done, as produced by 'git diff':
diff --git a/cpu/arm926ejs/at91/timer.c b/cpu/arm926ejs/at91/timer.c
index c84cb5e..a0a409e 100644
--- a/cpu/arm926ejs/at91/timer.c
+++ b/cpu/arm926ejs/at91/timer.c
@@ -91,6 +91,7 @@ unsigned long long get_ticks(void)
else/* we have rollover of incrementer */
timestamp += (0x - lastinc) + now;
lastinc = now;
+ printf("Debug: timestamp=%lu\n", timestamp);
return timestamp;
}
diff --git a/include/configs/at91sam9260ek.h b/include/configs/at91sam9260ek.h
index e46c9d6..e32de31 100644
--- a/include/configs/at91sam9260ek.h
+++ b/include/configs/at91sam9260ek.h
@@ -85,11 +85,14 @@
#undef CONFIG_CMD_IMLS
#undef CONFIG_CMD_LOADS
#undef CONFIG_CMD_SOURCE
+#undef CONFIG_CMD_FLASH
#define CONFIG_CMD_PING1
#define CONFIG_CMD_DHCP1
#define CONFIG_CMD_NAND1
#define CONFIG_CMD_USB 1
+#define CONFIG_CMD_MTDPARTS 1
+//#define CONFIG_CMD_UBI 1
/* SDRAM */
#define CONFIG_NR_DRAM_BANKS 1
@@ -126,6 +129,17 @@
#define CONFIG_SYS_NAND_READY_PIN AT91_PIN_PC13
#endif
+/* Ubi */
+#define CONFIG_SYS_USE_UBI
+#define CONFIG_RBTREE
+#define CONFIG_MTD_PARTITIONS
+#define MTDIDS_DEFAULT "nand0=at_nand"
+#define MTDPARTS_DEFAULT "mtdparts=at91_nand:128k(bootstrap)," \
+ "256k(U-Boot)," \
+ "128k(U-Bootenv1)," \
+ "128k(U-Bootenv2)," \
+ "-(ubifs)"
+
/* NOR flash - no real flash on this board */
#define CONFIG_SYS_NO_FLASH1
@@ -189,11 +203,10 @@
#define CONFIG_ENV_SIZE0x2 /* 1 sector = 128 kB */
#define CONFIG_BOOTCOMMAND "nand read 0x2200 0xA 0x20; bootm"
#define CONFIG_BOOTARGS"console=ttyS0,115200 "
\
- "root=/dev/mtdblock5 " \
"mtdparts=at91_nand:128k(bootstrap)ro," \
"256k(uboot)ro,128k(env1)ro," \
- "128k(env2)ro,2M(linux),-(root) " \
- "rw rootfstype=jffs2"
+ "128k(env2)ro,-(ubifs) "\
+ "ubi.mtd=4"
#endif
--
Anders Darander
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] No nandflash found if CONFIG_CMD_UBI is enabled.
Hi Anders, On Tuesday 02 June 2009 09:08:38 Anders Darander wrote: > I'm trying to enable the UBI-support in U-Boot (later intending to > also enable the UBIFS-support). This is on a AT91SAM9260-based system. > I've verified the same behaviour using both the > at91sam9260ek_nandflash_config and a forward-ported patch for the > Olimex sam9_l9260 board. Currently I'm concentrating on the > at91sam9260ek_nandflash_config, as this one is in the U-Boot > repository. > > However, once I enable the UBI-support, the nand-flash chip is not > detected... I've tried to trace the problem, and I've found that it is > timer-related. Which options did you define to enable UBI? apollon.h should be helpful as an example here. Ah, I see them in your patch below. Looks ok on first glance. > It seems that once I enable CONFIG_CMD_UBI, the timer > does not work (the debug-printf in the get_ticks()-function in the > supplied patch is not printing). If I comment out CONFIG_CMD_UBI, > U-Boot continously prints stuff like: > Debug: timestamp=6 > Debug: timestamp=10215 > Debug: timestamp=21556 > which is expected. > > I'm compiling by running: > make clean > make at91sam9260ek_nandflash_config > make > and then flashing u-boot.bin to the board. > > The supplied patch works, unless the '#define CONFIG_CMD_UBI 1' > is uncommented, in which case the get_ticks function in > cpu/arm926ejs/at91/timer.c never seems to be called. I've sofar been > unable to understand why. Strange. This should have nothing to do with UBI at all. Sorry I have no clue where this problem is coming from. Perhaps a "sleeping" issue that is triggered by larger image size? Best regards, 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] potential Uboot Ping problem
> -Original Message- > From: u-boot-boun...@lists.denx.de > [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Peter Tyser > Sent: Tuesday, June 02, 2009 3:53 AM > To: Steven Zedeck > Cc: u-boot@lists.denx.de > Subject: Re: [U-Boot] potential Uboot Ping problem > > Hi Steven, > > On Mon, 2009-06-01 at 08:03 -0700, Steven Zedeck wrote: > > I guess thats good news. I looked inside the cmd_ping code > a bit. I bet > > there's a "while" loop somewhere that is waiting for > something and may not > > have a timeout loop. Any ideas? > > > > Thanks, > > Steve > > Please don't top post, it makes the conversation hard to follow. > http://www.caliburn.nl/topposting.html > > > Premi, Sanjeev wrote: > > > > > >> -Original Message- > > >> From: u-boot-boun...@lists.denx.de > > >> [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Steven Zedeck > > >> Sent: Monday, June 01, 2009 8:05 PM > > >> To: u-boot@lists.denx.de > > >> Subject: [U-Boot] potential Uboot Ping problem > > >> > > >> > > >> Hi, > > >> It appears the ping in UBOOT is broken. The ping works fine > > >> if you have a > > >> network connection. But if the network connection is > > >> disconnected the ping > > >> hangs the system. There is no response to Control-C either. I > > >> have to power > > >> cycle the proto to get back to a UBOOT prompt. Is this a > > >> known issue or did > > >> I possibly break something? > > >> > > >> I have a board based on the Atmel AT91SAM9RL-EK. My theory is > > >> that it "may" > > >> be a generic problem with the uboot ping. I can't confirm > > >> that since the > > >> only hardware I have is our protos. > > > > > > It was noticed on the OMAP3EVM last FRI and we were suspecting > > > it to be problem with the omap3 board configuration itself. > > > (Though did not spend much time in debug). > > > > > > Now, I too get a feeling that it could be a generic problem. > > > > > > Best regards, > > > Sanjeev > > >> > > >> Does anyone else have a board with another MAC/PHY that you > > >> can try this on? > > Ideally, if there is no link, the ping command should just exit > gracefully without attempting network operations. Eg on my 8561-based > board with no cables plugged in: > => ping 192.168.1.1 > Auto-neg error, defaulting to 10BT/HD > eTSEC1: No link. > Auto-neg error, defaulting to 10BT/HD > eTSEC2: No link. > ping failed; host 192.168.1.1 is not alive > > . > > The tsec driver's init function returns -1 when link isn't detected. > Perhaps your ethernet driver should do the same? > > What happens if you ping a non-existent IP address? Does > that also hang > the board? Do other network operations hang the board if no ethernet > cable is plugged in? Here is a session from OMAP3EVM: OMAP3_EVM # setenv autoload no OMAP3_EVM # dhcp smc911x: initializing smc911x: detected LAN9115 controller smc911x: phy initialized smc911x: MAC 00:50:c2:7e:88:72 BOOTP broadcast 1 BOOTP broadcast 2 DHCP client bound to address 192.168.1.10 OMAP3_EVM # ping 192.168.1.1 smc911x: initializing smc911x: detected LAN9115 controller smc911x: phy initialized smc911x: MAC 00:50:c2:7e:88:72 ping failed; host 192.168.1.1 is not alive OMAP3_EVM # > Best, > Peter > > ___ > 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] pci bus scan in u-boot-1.0.2
Dear xiaoguizi007, In message <20207172.786581243919864464.javamail.corem...@bj163app34.163.com> you wrote: > > I'm tring using pci function of u-boot-1.0.2. But while the programm > run into function pci_hose_scan_bus() in /drivers/pci.c, it looks like go to > dead and will never run. So, I assert some debug infomation, and then get the > problem,maybe it is p > ci_hose_##rw##_config_##size() function. Because this function will never > return this time! > Can anybody help me! U-Boot 1.0.2 is extremely old. Please consider it unsupported and update to recent 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 The perversity of nature is nowhere better demonstrated by the fact that, when exposed to the same atmosphere, bread becomes hard while crackers become soft. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] MPC8313ERDB board reset problem
Hi im using mpc8313erdb board. and i have modified the u-boot 1.3.0 code to suit my needs. But the problem is that now as soon as power up the board, the initial msgs are dumped on the telnet...and then as soon as the prompt is displayedit resetsand keeps on doing the same... the thing is i dont know what change has caused thisit would be of great help if anyone can guide me identify wat component have i messed up... thanks and regards in advance Deepak Gopalakrishnan___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 3/5] net: Add Marvell Kirkwood gigabit ethernet driver
This patch adds a egiga driver for the Marvell Kirkwood SoC's.
Contributors:
Yotam Admon
Michael Blostein
Acked-by: Stefan Rose
Signed-off-by: Prafulla Wadaskar
---
Change log:
v2: updated all print messages to provide helpful info
drivers/net/Makefile |1 +
drivers/net/kirkwood_egiga.c | 664 ++
drivers/net/kirkwood_egiga.h | 561 +++
include/netdev.h |1 +
4 files changed, 1227 insertions(+), 0 deletions(-)
create mode 100644 drivers/net/kirkwood_egiga.c
create mode 100644 drivers/net/kirkwood_egiga.h
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index a360a50..f0c5654 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -40,6 +40,7 @@ COBJS-$(CONFIG_ENC28J60) += enc28j60.o
COBJS-$(CONFIG_FSLDMAFEC) += fsl_mcdmafec.o mcfmii.o
COBJS-$(CONFIG_GRETH) += greth.o
COBJS-$(CONFIG_INCA_IP_SWITCH) += inca-ip_sw.o
+COBJS-$(CONFIG_KIRKWOOD_EGIGA) += kirkwood_egiga.o
COBJS-$(CONFIG_DRIVER_KS8695ETH) += ks8695eth.o
COBJS-$(CONFIG_DRIVER_LAN91C96) += lan91c96.o
COBJS-$(CONFIG_MACB) += macb.o
diff --git a/drivers/net/kirkwood_egiga.c b/drivers/net/kirkwood_egiga.c
new file mode 100644
index 000..85cacdb
--- /dev/null
+++ b/drivers/net/kirkwood_egiga.c
@@ -0,0 +1,664 @@
+/*
+ * (C) Copyright 2009
+ * Marvell Semiconductor
+ * Written-by: Prafulla Wadaskar
+ *
+ * (C) Copyright 2003
+ * Ingo Assmus
+ *
+ * based on - Driver for MV64360X ethernet ports
+ * Copyright (C) 2002 rab...@galileo.co.il
+ *
+ * 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., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "kirkwood_egiga.h"
+
+/*
+ * smi_reg_read - miiphy_read callback function.
+ *
+ * Returns 16bit phy register value, or 0x on error
+ */
+static int smi_reg_read(char *devname, u8 phy_adr, u8 reg_ofs, u16 * data)
+{
+ struct eth_device *dev = eth_get_dev_by_name(devname);
+ struct kwgbe_device *dkwgbe = to_dkwgbe(dev);
+ struct kwgbe_registers *regs = dkwgbe->regs;
+ u32 smi_reg;
+ volatile u32 timeout;
+
+ /* Phyadr read request */
+ if (phy_adr == 0xEE && reg_ofs == 0xEE) {
+ *data = (u16) (KWGBEREG_RD(regs->phyadr) & 0x00ff);
+ return 0;
+ }
+ /* check parameters */
+ if (phy_adr > 0x1f) {
+ printf("Err..(%s) Invalid PHY address %d\n",
+ __FUNCTION__, phy_adr);
+ return -EFAULT;
+ }
+ if (reg_ofs > 0x1f) {
+ printf("Err..(%s) Invalid register offset %d\n",
+ __FUNCTION__, reg_ofs);
+ return -EFAULT;
+ }
+
+ timeout = KWGBE_PHY_SMI_TIMEOUT;
+ /* wait till the SMI is not busy */
+ do {
+ /* read smi register */
+ smi_reg = KWGBEREG_RD(regs->smi);
+ if (timeout-- == 0) {
+ printf("Err..(%s) SMI busy timeout\n", __FUNCTION__);
+ return -EFAULT;
+ }
+ } while (smi_reg & KWGBE_PHY_SMI_BUSY_MASK);
+
+ /* fill the phy address and regiser offset and read opcode */
+ smi_reg = (phy_adr << KWGBE_PHY_SMI_DEV_ADDR_OFFS)
+ | (reg_ofs << KWGBE_SMI_REG_ADDR_OFFS)
+ | KWGBE_PHY_SMI_OPCODE_READ;
+
+ /* write the smi register */
+ KWGBEREG_WR(regs->smi, smi_reg);
+
+ /*wait till read value is ready */
+ timeout = KWGBE_PHY_SMI_TIMEOUT;
+ do {
+ /* read smi register */
+ smi_reg = KWGBEREG_RD(regs->smi);
+ if (timeout-- == 0) {
+ printf("Err..(%s) SMI read ready timeout\n",
+ __FUNCTION__);
+ return -EFAULT;
+ }
+ } while (!(smi_reg & KWGBE_PHY_SMI_READ_VALID_MASK));
+
+ /* Wait for the data to update in the SMI register */
+ for (timeout = 0; timeout < KWGBE_PHY_SMI_TIMEOUT; timeout++) ;
+
+ *data = (u16) (KWGBEREG_RD(regs->smi) & KWGBE_PHY_SMI_DATA_MASK);
+
+ debug("%s:(adr %d, off %d) value= %04x\n", __FUNCTION__, phy_adr,
+ reg_ofs,
Re: [U-Boot] [PATCH v2] Marvell Sheevaplug Board support
> ... > > +#define CONFIG_MTDPARTS > "orion_nand:512k(uboot)," \ > > + "1...@4m(psm),3...@1m(kernel),1...@5m(rootfs) rw\0" > > Is this weird partition setup intentional? No, This partition is setup purposely on this board, specially apps in the RFS stack need it. I wish to keep it there to remove dependency and to establish smooth system bring up. Otherwise user has to add it manually after new uboot flash to work system correctly. but if it conflicts with common u-boot guidelines, I can remove it. Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 10/10] MPC512x: add support for ARIA board
Hi Wolfgang,
On Saturday 16 May 2009 10:47:46 Wolfgang Denk wrote:
> ARIA is a MPC5121E based COM Express module by Dave/DENX.
>
> Signed-off-by: Wolfgang Denk
> Cc: John Rigby
Please find some mostly nitpicking comments below. (Sorry about the late
review - I just stumbled over a few issue while using this port as basis for a
port for an MPC5123 board from esd).
> diff --git a/board/davedenx/aria/Makefile b/board/davedenx/aria/Makefile
> new file mode 100644
> index 000..48c2a83
> --- /dev/null
> +++ b/board/davedenx/aria/Makefile
> @@ -0,0 +1,53 @@
> +#
> +# (C) Copyright 2009 Wolfgang Denk
> +#
> +# 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
> +
> +$(shell mkdir -p $(OBJTREE)/board/freescale/common)
Is this really needed?
> +
> +LIB = $(obj)lib$(BOARD).a
> +
> +COBJS-y := $(BOARD).o
> +
> +COBJS:= $(COBJS-y)
> +SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
> +OBJS := $(addprefix $(obj),$(COBJS))
> +SOBJS:= $(addprefix $(obj),$(SOBJS))
> +
> +$(LIB): $(obj).depend $(OBJS)
> +
> + $(AR) $(ARFLAGS) $@ $(OBJS)
Please remove this empty line above.
> +
> +clean:
> + rm -f $(SOBJS) $(OBJS)
> +
> +distclean: clean
> + rm -f $(LIB) core *.bak $(obj).depend
> +
> +#
> +
> +# defines $(obj).depend target
> +include $(SRCTREE)/rules.mk
> +
> +sinclude $(obj).depend
> +
> +#
> diff --git a/board/davedenx/aria/aria.c b/board/davedenx/aria/aria.c
> new file mode 100644
> index 000..4d26713
> --- /dev/null
> +++ b/board/davedenx/aria/aria.c
> @@ -0,0 +1,317 @@
> +/*
> + * (C) Copyright 2009 Wolfgang Denk
> + * (C) Copyright 2009 Dave Srl www.dave.eu
> + *
> + * See file CREDITS for list of people who contributed to this
> + * project.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
> + * MA 02111-1307 USA
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#ifdef CONFIG_MISC_INIT_R
> +#include
> +#endif
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +extern void ide_set_reset(int idereset);
> +
> +/* Clocks in use */
> +#define SCCR1_CLOCKS_EN (CLOCK_SCCR1_CFG_EN |
> \
> + CLOCK_SCCR1_LPC_EN | \
> + CLOCK_SCCR1_PSC_EN(CONFIG_PSC_CONSOLE) | \
> + CLOCK_SCCR1_PSCFIFO_EN | \
> + CLOCK_SCCR1_DDR_EN | \
> + CLOCK_SCCR1_FEC_EN | \
> + CLOCK_SCCR1_PATA_EN | \
> + CLOCK_SCCR1_PCI_EN | \
> + CLOCK_SCCR1_TPR_EN)
> +
> +#define SCCR2_CLOCKS_EN (CLOCK_SCCR2_MEM_EN | \
> + CLOCK_SCCR2_SPDIF_EN | \
> + CLOCK_SCCR2_DIU_EN | \
> + CLOCK_SCCR2_I2C_EN)
> +
> +#define CSAW_START(start)((start) & 0x)
> +#define CSAW_STOP(start, size) (((start) + (size) - 1) >> 16)
> +
> +long int fixed_sdram(void);
> +
> +int board_early_init_f(void)
> +{
> + volatile immap_t *im = (immap_t *) CONFIG_SYS_IMMR;
> + u32 spridr;
> +
> + /*
> + * Initialize Local Window for the On Board FPGA access
> + */
> + out_be32(&im->sysconf.lpcs2aw,
> + CSAW
[U-Boot] JFFS2 with NAND flash is very SLOW ...
Hi all, Currently I work with the lpc3250 board of Phytec. I wish boot my Linux kernel from a NAND flash formatted with JFFS2. Here my current configuration: [...] #define CONFIG_CMD_NAND #define CONFIG_SYS_MAX_FLASH_BANKS 1 #define CONFIG_SYS_MAX_NAND_DEVICE 1 #define CONFIG_SYS_NAND_BASE0x2002 #define NAND_MAX_CHIPS 1 #define CONFIG_ENV_IS_IN_NAND [...] #define CONFIG_CMD_JFFS2 [...] #define CONFIG_JFFS2_NAND #undef CONFIG_JFFS2_CMDLINE #define CONFIG_JFFS2_DEV"nand0" #define CONFIG_JFFS2_PART_SIZE 0x00C0 #define CONFIG_JFFS2_PART_OFFSET0x000C8000 [...] It works... but I have a very big problem : it's very very slow How can I decrease the time to load the kernel image? I try with u-boot 1.3.3, 1.3.4 and 2009.03 but the problem is always present... Can you help me please? Thanks in advance, Best Regards Pierre ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 4/5] Marvell Sheevaplug Board support
Reference: http://plugcomputer.org/ http://openplug.org/plugwiki/index.php/Das_U-boot_plug_support This patch is tested for- 1. Boot from DRAM/NAND flash 2. File transfer using tftp 3. NAND flash read/write/erase 4. Linux kernel and RFS Boot from NAND Signed-off-by: Prafulla Wadaskar --- Change log: v2: updated as per feedback for v1 v3: updated as per feedback for v2 MAINTAINERS |4 + MAKEALL |1 + Makefile |4 +- board/Marvell/sheevaplug/Makefile | 51 + board/Marvell/sheevaplug/config.mk| 25 + board/Marvell/sheevaplug/sheevaplug.c | 133 +++ board/Marvell/sheevaplug/sheevaplug.h | 37 +++ include/configs/sheevaplug.h | 191 + 8 files changed, 445 insertions(+), 1 deletions(-) create mode 100644 board/Marvell/sheevaplug/Makefile create mode 100644 board/Marvell/sheevaplug/config.mk create mode 100644 board/Marvell/sheevaplug/sheevaplug.c create mode 100644 board/Marvell/sheevaplug/sheevaplug.h create mode 100644 include/configs/sheevaplug.h diff --git a/MAINTAINERS b/MAINTAINERS index bf076b9..2474481 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -655,6 +655,10 @@ Hugo Villeneuve SFFSDR ARM926EJS +Prafulla Wadaskar + + sheevaplug ARM926EJS (Kirkwood SoC) + Richard Woodruff omap2420h4 ARM1136EJS diff --git a/MAKEALL b/MAKEALL index 6719d7b..e9b3fa7 100755 --- a/MAKEALL +++ b/MAKEALL @@ -517,6 +517,7 @@ LIST_ARM9=" \ omap730p2 \ sbc2410x\ scb9328 \ + sheevaplug \ smdk2400\ smdk2410\ trab\ diff --git a/Makefile b/Makefile index 8144ecd..daebc59 100644 --- a/Makefile +++ b/Makefile @@ -2882,6 +2882,9 @@ sbc2410x_config: unconfig scb9328_config : unconfig @$(MKCONFIG) $(@:_config=) arm arm920t scb9328 NULL imx +sheevaplug_config: unconfig + @$(MKCONFIG) $(@:_config=) arm arm926ejs $(@:_config=) Marvell kirkwood + smdk2400_config: unconfig @$(MKCONFIG) $(@:_config=) arm arm920t smdk2400 samsung s3c24x0 @@ -3110,7 +3113,6 @@ omap2420h4_config : unconfig qong_config: unconfig @$(MKCONFIG) $(@:_config=) arm arm1136 qong davedenx mx31 - # ## ARM1176 Systems # diff --git a/board/Marvell/sheevaplug/Makefile b/board/Marvell/sheevaplug/Makefile new file mode 100644 index 000..e378b5b --- /dev/null +++ b/board/Marvell/sheevaplug/Makefile @@ -0,0 +1,51 @@ +# +# (C) Copyright 2009 +# Marvell Semiconductor +# Written-by: Prafulla Wadaskar +# +# 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., 51 Franklin Street, Fifth Floor, Boston, +# MA 02110-1301 USA +# + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(BOARD).a + +COBJS := sheevaplug.o + +SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS)) +SOBJS := $(addprefix $(obj),$(SOBJS)) + +$(LIB):$(obj).depend $(OBJS) $(SOBJS) + $(AR) $(ARFLAGS) $@ $(OBJS) $(SOBJS) + +clean: + rm -f $(SOBJS) $(OBJS) + +distclean: clean + rm -f $(LIB) core *.bak .depend + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/board/Marvell/sheevaplug/config.mk b/board/Marvell/sheevaplug/config.mk new file mode 100644 index 000..a4ea769 --- /dev/null +++ b/board/Marvell/sheevaplug/config.mk @@ -0,0 +1,25 @@ +# +# (C) Copyright 2009 +# Marvell Semiconductor +# Written-by: Prafulla Wadaskar +# +# 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
[U-Boot] [PATCH] OMAP3EVM: fix typo. replace CS6 by CS5, no functionality change
Signed-off-by: Matthias Ludwig
---
> as predently the commit message does not correspond with the code
>
> it's a typo fix not, the current code work it does use the CS5 in reality
You are right, it's only a "typo fix".
Sorry for delayed fixing...
btw: i hope this kind of inline-commenting of a patch-mail is correct?!
best regards,
Matthias
board/omap3/evm/evm.c| 16
include/asm-arm/arch-omap3/cpu.h |5 +++--
2 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/board/omap3/evm/evm.c b/board/omap3/evm/evm.c
index c008c2e..5fd5efa 100644
--- a/board/omap3/evm/evm.c
+++ b/board/omap3/evm/evm.c
@@ -92,17 +92,17 @@ void set_muxconf_regs(void)
static void setup_net_chip(void)
{
gpio_t *gpio3_base = (gpio_t *)OMAP34XX_GPIO3_BASE;
- gpmc_csx_t *gpmc_cs6_base = (gpmc_csx_t *)GPMC_CONFIG_CS6_BASE;
+ gpmc_csx_t *gpmc_cs5_base = (gpmc_csx_t *)GPMC_CONFIG_CS5_BASE;
ctrl_t *ctrl_base = (ctrl_t *)OMAP34XX_CTRL_BASE;
/* Configure GPMC registers */
- writel(NET_GPMC_CONFIG1, &gpmc_cs6_base->config1);
- writel(NET_GPMC_CONFIG2, &gpmc_cs6_base->config2);
- writel(NET_GPMC_CONFIG3, &gpmc_cs6_base->config3);
- writel(NET_GPMC_CONFIG4, &gpmc_cs6_base->config4);
- writel(NET_GPMC_CONFIG5, &gpmc_cs6_base->config5);
- writel(NET_GPMC_CONFIG6, &gpmc_cs6_base->config6);
- writel(NET_GPMC_CONFIG7, &gpmc_cs6_base->config7);
+ writel(NET_GPMC_CONFIG1, &gpmc_cs5_base->config1);
+ writel(NET_GPMC_CONFIG2, &gpmc_cs5_base->config2);
+ writel(NET_GPMC_CONFIG3, &gpmc_cs5_base->config3);
+ writel(NET_GPMC_CONFIG4, &gpmc_cs5_base->config4);
+ writel(NET_GPMC_CONFIG5, &gpmc_cs5_base->config5);
+ writel(NET_GPMC_CONFIG6, &gpmc_cs5_base->config6);
+ writel(NET_GPMC_CONFIG7, &gpmc_cs5_base->config7);
/* Enable off mode for NWE in PADCONF_GPMC_NWE register */
writew(readw(&ctrl_base ->gpmc_nwe) | 0x0E00, &ctrl_base->gpmc_nwe);
diff --git a/include/asm-arm/arch-omap3/cpu.h b/include/asm-arm/arch-omap3/cpu.h
index c544e0c..a4ce45a 100644
--- a/include/asm-arm/arch-omap3/cpu.h
+++ b/include/asm-arm/arch-omap3/cpu.h
@@ -84,9 +84,10 @@ typedef struct ctrl_id {
/* GPMC CS3/cs4/cs6 not avaliable */
#define GPMC_BASE (OMAP34XX_GPMC_BASE)
#define GPMC_CONFIG_CS00x60
-#define GPMC_CONFIG_CS60x150
+#define GPMC_CONFIG_CS50x150
+
#define GPMC_CONFIG_CS0_BASE (GPMC_BASE + GPMC_CONFIG_CS0)
-#define GPMC_CONFIG_CS6_BASE (GPMC_BASE + GPMC_CONFIG_CS6)
+#define GPMC_CONFIG_CS5_BASE (GPMC_BASE + GPMC_CONFIG_CS5)
#define GPMC_CONFIG_WP 0x10
#define GPMC_CONFIG_WIDTH 0x30
--
1.6.3.9.g6345
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] I wonder "---" in the patch file generated by the git-format-patch
Dear Wolfgang Denk, I have a question about git-format-patch usage. I generated the patch using git-format-patch. The my usage is the following : 1. pull latest git repo. 2. change the code 3. # git commit -a -s 4. insert commit & any other things. 5. # git-format-patch -1 So, I get patch. But, this patch's form is different with you said. First of all, the all comments is on the "---". But, you said all comments must belong below the "---" like this messages. : http://lists.denx.de/pipermail/u-boot/2009-June/053535.html It's different. What did I lose anything during the patching progress?? Can you tell me what is wrong?? Thanks to read. Best Regards, riverful ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Marvell MV88E1116 PHY Driver support
> -Original Message- > From: Ben Warren [mailto:biggerbadder...@gmail.com] > Sent: Saturday, May 30, 2009 9:36 PM > To: Prafulla Wadaskar > Cc: u-boot@lists.denx.de > Subject: Re: [PATCH] Marvell MV88E1116 PHY Driver support > > Hi Prafulla, > > > On Fri, May 29, 2009 at 11:34 PM, Prafulla Wadaskar > wrote: > > > Hi Ben > Thanks for accepting MV88E61xx driver code. > Ping for mv88f1116 driver... :-) > This is dependency for sheevaplug board support. > > I've already commented on this one. We don't currently have > a framework for PHYs and I don't want to add PHY support > ad-hoc. For now, PHY support needs to go in whatever > ethernet driver uses it. Hi Ben Don't you think keeping phy support in Ethernet driver will harm to keep it's generic approach? through development and reviews we always try to keep any driver generic so that it can be used by others. As of now apart from switch mv88e61xx, there is no phy support in driver/net/phy/. Being this first one- May I take this opportunity to help you to create a framework for PHYs? Regards.. Prafulla . . > > regards, > Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] update nand.h to support address more than 0x80000000
Hi all,
I found a bug in nand.h which prevent UBOOT to supprt large NAND chip.
The bug description as below:
In the original implementation, we use a wrapper function in
nand.h to facilitate nand_base function usage in other files,
like cmd_nand.c, nand_util.c etc.
However, the wrapper in nand.h is using off_t which is long type.
If we pass a address like 0x8000, which is allowed by nand_base.c,
the wrapper would recognize it as a negative num. So we would get a
huge num when this parameter get into nand_base.c
Fix it by replacing off_t to loff_t type.
Signed-off-by: Lei Wen
---
include/nand.h | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/include/nand.h b/include/nand.h
index 230aa62..293d481 100644
--- a/include/nand.h
+++ b/include/nand.h
@@ -36,28 +36,28 @@ typedef struct mtd_info nand_info_t;
extern int nand_curr_device;
extern nand_info_t nand_info[];
-static inline int nand_read(nand_info_t *info, off_t ofs, size_t *len,
u_char *buf)
+static inline int nand_read(nand_info_t *info, loff_t ofs, size_t *len,
u_char *buf)
{
return info->read(info, ofs, *len, (size_t *)len, buf);
}
-static inline int nand_write(nand_info_t *info, off_t ofs, size_t *len,
u_char *buf)
+static inline int nand_write(nand_info_t *info, loff_t ofs, size_t *len,
u_char *buf)
{
return info->write(info, ofs, *len, (size_t *)len, buf);
}
-static inline int nand_write_oob(nand_info_t *info, off_t ofs,
+static inline int nand_write_oob(nand_info_t *info, loff_t ofs,
struct mtd_oob_ops *ops)
{
return info->write_oob(info, ofs, ops);
}
-static inline int nand_block_isbad(nand_info_t *info, off_t ofs)
+static inline int nand_block_isbad(nand_info_t *info, loff_t ofs)
{
return info->block_isbad(info, ofs);
}
-static inline int nand_erase(nand_info_t *info, off_t off, size_t size)
+static inline int nand_erase(nand_info_t *info, loff_t off, size_t size)
{
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] move L2 cache enable/disable function to cache.c in the omap3 SoC directory
CC: Dirk Behme
Signed-off-by: HeungJun, Kim
---
The omap3 L2 cache enable/disable function in the cpu/arm_cortexa8/cpu.c moved
to cpu/arm_cortexa8/omap3/cache.c. Because, it must be CortexA8 ARCH generic
code below the cpu/arm_cortexa8.
This patches fixes the First issue in the following
http://lists.denx.de/pipermail/u-boot/2009-May/053433.html
The Second issue is fixed by
http://lists.denx.de/pipermail/u-boot/2009-May/053490.html
cpu/arm_cortexa8/cpu.c | 70 ++---
cpu/arm_cortexa8/omap3/Makefile |2 +-
cpu/arm_cortexa8/omap3/board.c |5 +-
cpu/arm_cortexa8/omap3/cache.c | 96 +++
include/asm-arm/cache.h | 31 +
5 files changed, 135 insertions(+), 69 deletions(-)
create mode 100644 cpu/arm_cortexa8/omap3/cache.c
create mode 100644 include/asm-arm/cache.h
diff --git a/cpu/arm_cortexa8/cpu.c b/cpu/arm_cortexa8/cpu.c
index 3e1780b..4675812 100644
--- a/cpu/arm_cortexa8/cpu.c
+++ b/cpu/arm_cortexa8/cpu.c
@@ -33,17 +33,13 @@
#include
#include
-#include
#include
+#include
#ifdef CONFIG_USE_IRQ
DECLARE_GLOBAL_DATA_PTR;
#endif
-#ifndef CONFIG_L2_OFF
-void l2cache_disable(void);
-#endif
-
static void cache_flush(void);
int cpu_init(void)
@@ -80,7 +76,7 @@ int cleanup_before_linux(void)
#ifndef CONFIG_L2_OFF
/* turn off L2 cache */
- l2cache_disable();
+ l2_cache_disable();
/* invalidate L2 cache also */
v7_flush_dcache_all(get_device_type());
#endif
@@ -89,72 +85,14 @@ int cleanup_before_linux(void)
asm("mcr p15, 0, %0, c7, c10, 4": :"r"(i));
#ifndef CONFIG_L2_OFF
- l2cache_enable();
+ l2_cache_enable();
#endif
return 0;
}
-void l2cache_enable()
-{
- unsigned long i;
- volatile unsigned int j;
-
- /* ES2 onwards we can disable/enable L2 ourselves */
- if (get_cpu_rev() >= CPU_3XX_ES20) {
- __asm__ __volatile__("mrc p15, 0, %0, c1, c0, 1":"=r"(i));
- __asm__ __volatile__("orr %0, %0, #0x2":"=r"(i));
- __asm__ __volatile__("mcr p15, 0, %0, c1, c0, 1":"=r"(i));
- } else {
- /* Save r0, r12 and restore them after usage */
- __asm__ __volatile__("mov %0, r12":"=r"(j));
- __asm__ __volatile__("mov %0, r0":"=r"(i));
-
- /*
-* GP Device ROM code API usage here
-* r12 = AUXCR Write function and r0 value
-*/
- __asm__ __volatile__("mov r12, #0x3");
- __asm__ __volatile__("mrc p15, 0, r0, c1, c0, 1");
- __asm__ __volatile__("orr r0, r0, #0x2");
- /* SMI instruction to call ROM Code API */
- __asm__ __volatile__(".word 0xE1600070");
- __asm__ __volatile__("mov r0, %0":"=r"(i));
- __asm__ __volatile__("mov r12, %0":"=r"(j));
- }
-
-}
-
-void l2cache_disable()
-{
- unsigned long i;
- volatile unsigned int j;
-
- /* ES2 onwards we can disable/enable L2 ourselves */
- if (get_cpu_rev() >= CPU_3XX_ES20) {
- __asm__ __volatile__("mrc p15, 0, %0, c1, c0, 1":"=r"(i));
- __asm__ __volatile__("bic %0, %0, #0x2":"=r"(i));
- __asm__ __volatile__("mcr p15, 0, %0, c1, c0, 1":"=r"(i));
- } else {
- /* Save r0, r12 and restore them after usage */
- __asm__ __volatile__("mov %0, r12":"=r"(j));
- __asm__ __volatile__("mov %0, r0":"=r"(i));
-
- /*
-* GP Device ROM code API usage here
-* r12 = AUXCR Write function and r0 value
-*/
- __asm__ __volatile__("mov r12, #0x3");
- __asm__ __volatile__("mrc p15, 0, r0, c1, c0, 1");
- __asm__ __volatile__("bic r0, r0, #0x2");
- /* SMI instruction to call ROM Code API */
- __asm__ __volatile__(".word 0xE1600070");
- __asm__ __volatile__("mov r0, %0":"=r"(i));
- __asm__ __volatile__("mov r12, %0":"=r"(j));
- }
-}
-
static void cache_flush(void)
{
asm ("mcr p15, 0, %0, c7, c5, 0": :"r" (0));
}
+
diff --git a/cpu/arm_cortexa8/omap3/Makefile b/cpu/arm_cortexa8/omap3/Makefile
index b96b3dd..f83036b 100644
--- a/cpu/arm_cortexa8/omap3/Makefile
+++ b/cpu/arm_cortexa8/omap3/Makefile
@@ -26,7 +26,7 @@ include $(TOPDIR)/config.mk
LIB= $(obj)lib$(SOC).a
SOBJS := lowlevel_init.o
-COBJS := sys_info.o board.o clock.o interrupts.o mem.o syslib.o
+COBJS := sys_info.o board.o clock.o interrupts.o mem.o syslib.o cache.o
SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS))
diff --git a/cpu/arm_cortexa8/omap3/board.c b/cpu/arm_cortexa8/omap3/board.c
index 51d5cf6..439ea6a 100644
--- a/cpu/arm_cortexa8/omap3/board.c
+++ b/cpu/arm_cortexa8/omap3/board.c
@@ -36,6 +36,7 @@
#include
#include
#include
+#include
[U-Boot] Enable mtdparts
Hello All, I have u-boot-1.3.0 running on mpc8313erdb board, and we have received it with the bsp from freescale. Anyways the u-boot is fine. But they have disabled 'mtdparts' command. And I would like to enable "mtdparts" command. I read the section 5.9.3.5 regarding mtd partition creation ... I did the changes according to this section, but I could not able to find option to enable "mtdparts" command enable. (http://www.denx.de/wiki/view/DULG/UBootCmdGroupFlash#Section_5.9.3.5) Could anyone please let me know the approach to how to enable the mtdparts command in u-boot ? ? ? Also do I need to modify the dts file with respect to partition requirement ? ? ? Kindly please acknowledge ... thank you. Kind Regards, Vijay Nikam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] Marvell Sheevaplug Board support
Dear Prafulla Wadaskar, In message <73173d32e9439e4abb5151606c3e19e201cfbdc...@sc-vexch1.marvell.com> you wrote: > > ... > > > +#define CONFIG_MTDPARTS =09 > > "orion_nand:512k(uboot)," \ > > > + "1...@4m(psm),3...@1m(kernel),1...@5m(rootfs) rw\0" > >=20 > > Is this weird partition setup intentional? > No, > This partition is setup purposely on this board, specially apps in the RFS > stack need it. > I wish to keep it there to remove dependency and to establish smooth system > bring up. > Otherwise user has to add it manually after new uboot flash to work system > correctly. So yes, it was intentional, right? > but if it conflicts with common u-boot guidelines, I can remove it. No, it does not conflict with anything. It just looked weird to me and I wanted to make sure it was intentional and not a missed problem. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Why can you only have two doors on a chicken coop? If it had four it would be a chicken sedan. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] JFFS2 with NAND flash is very SLOW ...
Dear Pierre, > It works... but I have a very big problem : it's very very slow How can > I decrease the time to load the kernel image? > I try with u-boot 1.3.3, 1.3.4 and 2009.03 but the problem is always > present... I have tried to boot from nand with 1.3.4 and 2009.03. I can tell you that 2009.03 is much faster then 1.3.4 to boot from a formatted JFFS2 nand. > Can you help me please? What is the size of the partition used to store the kernel? I suggest to use a small partition to store the kernel (5M by exemple something like 10M if you have an initramfs). You should have something like this: MTD1 u-boot 2M MTD2 kernel 5M MTD3 content remainingM Sylvain Cote ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot This electronic message may contain proprietary and confidential information of Verint Systems Inc., its affiliates and/or subsidiaries. The information is intended to be for the use of the individual(s) or entity(ies) named above. If you are not the intended recipient (or authorized to receive this e-mail for the intended recipient), you may not use, copy, disclose or distribute to anyone this message or any information contained in this message. If you have received this electronic message in error, please notify us by replying to this e-mail. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] JFFS2 with NAND flash is very SLOW ...
In my side: MTD0 (720kB): U-boot MTD1 (80kB) : env. Variables MTD2 (12MB) : kernel + initramfs MTD3 (50MB) : rootfs If it exists a difference between 2009.03 and 1.3.3 it is not sufficient. It is very slow in both versions. It takes more than 1 minutes to obtain the result of "fsinfo" command !!! Thanks for your help, Pierre -Message d'origine- De : u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] De la part de Cote, Sylvain Envoyé : mardi 2 juin 2009 14:22 À : Pierre Savary; u-boot-us...@lists.sourceforge.net; u-boot@lists.denx.de Objet : Re: [U-Boot] JFFS2 with NAND flash is very SLOW ... Dear Pierre, > It works... but I have a very big problem : it's very very slow How can > I decrease the time to load the kernel image? > I try with u-boot 1.3.3, 1.3.4 and 2009.03 but the problem is always > present... I have tried to boot from nand with 1.3.4 and 2009.03. I can tell you that 2009.03 is much faster then 1.3.4 to boot from a formatted JFFS2 nand. > Can you help me please? What is the size of the partition used to store the kernel? I suggest to use a small partition to store the kernel (5M by exemple something like 10M if you have an initramfs). You should have something like this: MTD1 u-boot 2M MTD2 kernel 5M MTD3 content remainingM Sylvain Cote ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot This electronic message may contain proprietary and confidential information of Verint Systems Inc., its affiliates and/or subsidiaries. The information is intended to be for the use of the individual(s) or entity(ies) named above. If you are not the intended recipient (or authorized to receive this e-mail for the intended recipient), you may not use, copy, disclose or distribute to anyone this message or any information contained in this message. If you have received this electronic message in error, please notify us by replying to this e-mail. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] Create the S5PC100 SoC code under the cpu/arm_cortesa8/
Signed-off-by: HeungJun, Kim --- This patch is the new processor - S5PC100's SoC code & headers. This patch consists of 2 files. The First file is to create the new SoC code related with S5PC100 application processor. It's located in ther cpu/arm_cortesa8/s5pc100. The Second file is to create the new SoC header related with S5PC100 application processor. It's located in ther include/asm-arm/s5pc100. This file is the First. cpu/arm_cortexa8/s5pc100/Makefile | 48 +++ cpu/arm_cortexa8/s5pc100/config.mk| 36 ++ cpu/arm_cortexa8/s5pc100/cpu_init.S | 196 + cpu/arm_cortexa8/s5pc100/interrupts.c | 218 + cpu/arm_cortexa8/s5pc100/speed.c | 159 5 files changed, 657 insertions(+), 0 deletions(-) create mode 100644 cpu/arm_cortexa8/s5pc100/Makefile create mode 100644 cpu/arm_cortexa8/s5pc100/config.mk create mode 100644 cpu/arm_cortexa8/s5pc100/cpu_init.S create mode 100644 cpu/arm_cortexa8/s5pc100/interrupts.c create mode 100644 cpu/arm_cortexa8/s5pc100/speed.c diff --git a/cpu/arm_cortexa8/s5pc100/Makefile b/cpu/arm_cortexa8/s5pc100/Makefile new file mode 100644 index 000..4688533 --- /dev/null +++ b/cpu/arm_cortexa8/s5pc100/Makefile @@ -0,0 +1,48 @@ +# +# (C) Copyright 2000-2003 +# Wolfgang Denk, DENX Software Engineering, w...@denx.de. +# +# (C) Copyright 2008 +# Guennadi Liakhovetki, DENX Software Engineering, +# +# 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$(SOC).a + +COBJS-y= interrupts.o +COBJS-$(CONFIG_S5PC100)+= cpu_init.o speed.o + +OBJS := $(addprefix $(obj),$(SOBJS) $(COBJS-y)) + +all:$(obj).depend $(LIB) + +$(LIB):$(OBJS) + $(AR) $(ARFLAGS) $@ $(OBJS) + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/cpu/arm_cortexa8/s5pc100/config.mk b/cpu/arm_cortexa8/s5pc100/config.mk new file mode 100644 index 000..e05d7ae --- /dev/null +++ b/cpu/arm_cortexa8/s5pc100/config.mk @@ -0,0 +1,36 @@ +# +# (C) Copyright 2002 +# Gary Jennejohn, DENX Software Engineering, +# +# 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 +# +PLATFORM_RELFLAGS += -fno-strict-aliasing -fno-common -ffixed-r8 \ + -msoft-float + +# Make ARMv5 to allow more compilers to work, even though its v6. +PLATFORM_CPPFLAGS += -march=armv5t +# = +# +# Supply options according to compiler version +# +# = +PLATFORM_CPPFLAGS +=$(call cc-option) +PLATFORM_CPPFLAGS +=$(call cc-option,-mno-thumb-interwork,) +PLATFORM_RELFLAGS +=$(call cc-option,-mshort-load-bytes,\ + $(call cc-option,-malignment-traps,)) diff --git a/cpu/arm_cortexa8/s5pc100/cpu_init.S b/cpu/arm_cortexa8/s5pc100/cpu_init.S new file mode 100644 index 000..4510049 --- /dev/null +++ b/cpu/arm_cortexa8/s5pc100/cpu_init.S @@ -0,0 +1,196 @@ +/* + * Originates from Samsung's u-boot 1.1.6 port to S5PC1xx + * + * Copyright (C) 2008 + * Guennadi Liakhovetki, DENX Software Engineering, + + * Copyright (C) 2009 + * Inki Dae, SAMSUNG Electronics, + * Heungjun Kim, SAMSUNG Electronics, + * Minkyu Kang, SAMSUNG Electronics, + * + * See file CRED
[U-Boot] [PATCH 2/2] Create the S5PC100 SoC header under the include/asm-arm/arch-s5pc100
Signed-off-by: HeungJun, Kim --- This patch is the new processor - S5PC100's SoC code & headers. This patch consists of 2 files. The First file is to create the new SoC code related with S5PC100 application processor. It's located in ther cpu/arm_cortesa8/s5pc100. The Second file is to create the new SoC header related with S5PC100 application processor. It's located in ther include/asm-arm/s5pc100. This file is the Second. include/asm-arm/arch-s5pc100/clock.h | 137 +++ include/asm-arm/arch-s5pc100/cpu.h | 292 +++ include/asm-arm/arch-s5pc100/gpio.h | 580 ++ include/asm-arm/arch-s5pc100/hardware.h | 63 include/asm-arm/arch-s5pc100/sys_proto.h | 25 ++ include/asm-arm/arch-s5pc100/uart.h | 94 + include/asm-arm/arch-s5pc100/watchdog.h | 39 ++ 7 files changed, 1230 insertions(+), 0 deletions(-) create mode 100644 include/asm-arm/arch-s5pc100/clock.h create mode 100644 include/asm-arm/arch-s5pc100/cpu.h create mode 100644 include/asm-arm/arch-s5pc100/gpio.h create mode 100644 include/asm-arm/arch-s5pc100/hardware.h create mode 100644 include/asm-arm/arch-s5pc100/sys_proto.h create mode 100644 include/asm-arm/arch-s5pc100/uart.h create mode 100644 include/asm-arm/arch-s5pc100/watchdog.h diff --git a/include/asm-arm/arch-s5pc100/clock.h b/include/asm-arm/arch-s5pc100/clock.h new file mode 100644 index 000..c703eec --- /dev/null +++ b/include/asm-arm/arch-s5pc100/clock.h @@ -0,0 +1,137 @@ +/* + * (C) Copyright 2009 + * Inki Dae, SAMSUNG Electronics, + * Heungjun Kim, SAMSUNG Electronics, + * Minkyu Kang, SAMSUNG Electronics, + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, + * MA 02111-1307 USA + */ + +/* + * Clock control + */ +#define S5P_CLKREG(x) (S5P_PA_CLK + (x)) + +/* Clock Register */ +#define S5P_APLL_LOCK S5P_CLKREG(0x0) +#define S5P_MPLL_LOCK S5P_CLKREG(0x4) +#define S5P_EPLL_LOCK S5P_CLKREG(0x8) +#define S5P_HPLL_LOCK S5P_CLKREG(0xc) + +#define S5P_APLL_CON S5P_CLKREG(0x100) +#define S5P_MPLL_CON S5P_CLKREG(0x104) +#define S5P_EPLL_CON S5P_CLKREG(0x108) +#define S5P_HPLL_CON S5P_CLKREG(0x10c) + +#define S5P_CLK_SRC0 S5P_CLKREG(0x200) +#define S5P_CLK_SRC1 S5P_CLKREG(0x204) +#define S5P_CLK_SRC2 S5P_CLKREG(0x208) +#define S5P_CLK_SRC3 S5P_CLKREG(0x20c) + +#define S5P_CLK_DIV0 S5P_CLKREG(0x300) +#define S5P_CLK_DIV1 S5P_CLKREG(0x304) +#define S5P_CLK_DIV2 S5P_CLKREG(0x308) +#define S5P_CLK_DIV3 S5P_CLKREG(0x30c) +#define S5P_CLK_DIV4 S5P_CLKREG(0x310) + +#define S5P_CLK_OUTS5P_CLKREG(0x400) + +#define S5P_CLK_GATE_D00 S5P_CLKREG(0x500) +#define S5P_CLK_GATE_D01 S5P_CLKREG(0x504) +#define S5P_CLK_GATE_D02 S5P_CLKREG(0x508) +#define S5P_CLK_GATE_D10 S5P_CLKREG(0x520) +#define S5P_CLK_GATE_D11 S5P_CLKREG(0x524) +#define S5P_CLK_GATE_D12 S5P_CLKREG(0x528) +#define S5P_CLK_GATE_D13 S5P_CLKREG(0x530) +#define S5P_CLK_GATE_D14 S5P_CLKREG(0x534) +#define S5P_CLK_GATE_D20 S5P_CLKREG(0x540) +#define S5P_CLK_GATE_SCLK0 S5P_CLKREG(0x560) +#define S5P_CLK_GATE_SCLK1 S5P_CLKREG(0x564) + +/* + * Clock control - Others + */ +#define S5P_OTHERS_REG_BASE(x) (S5P_PA_CLK_OTHERS + (x)) +#define S5P_OTHERS_BASES5P_OTHERS_REG_BASE(0x0) +#define S5P_SW_RST S5P_OTHERS_REG_BASE(0x0) +#define S5P_ONENAND_RSTS5P_OTHERS_REG_BASE(0x8) +#define S5P_GENERAL_CTRL S5P_OTHERS_REG_BASE(0x100) +#define S5P_GENERAL_STATUS S5P_OTHERS_REG_BASE(0x104) +#define S5P_MEM_SYS_CFGS5P_OTHERS_REG_BASE(0x200) +#define S5P_CAM_MUX_SELS5P_OTHERS_REG_BASE(0x300) +#define S5P_MIXER_OUT_SEL S5P_OTHERS_REG_BASE(0x304) +#define S5P_LPMP3_MODE_SEL S5P_OTHERS_REG_BASE(0x308) +#define S5P_MIPI_PHY_CON0 S5P_OTHERS_REG_BASE(0x400) +#define S5P_MIPI_PHY_CON1 S5P_OTHERS_REG_BASE(0x414) +#define S5P_HDMI_PHY_CON0 S5P_OTHERS_REG_BASE(0x420) + +#ifndef __ASSEMBLY__ + +/* Cl
Re: [U-Boot] JFFS2 with NAND flash is very SLOW ...
> In my side: > MTD0 (720kB): U-boot > MTD1 (80kB) : env. Variables > MTD2 (12MB) : kernel + initramfs > MTD3 (50MB) : rootfs Maybe it will not help you but I have MTD0 (all the nand 256M) MTD1 uboot+ embedded config 2M RAW MTD2 1M JFFS2 MTD5 config 5M JFFS2 MTD3 Kernel + initramfs 12M JFFS2 MTD4 KernelBKp 12M JFFS2 MTD5 content 224M Scanning and fsload of the MTD3 partition take 3 seconds with 2009.03 With 1.3.4 it was something like 6-10 seconds. But never 1 minute. I have seen that when scanning the content partition of 224M. > If it exists a difference between 2009.03 and 1.3.3 it is not sufficient. It > is very slow in both versions. It takes more than 1 minutes to obtain the > result of "fsinfo" command !!! sYLVAIN ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot This electronic message may contain proprietary and confidential information of Verint Systems Inc., its affiliates and/or subsidiaries. The information is intended to be for the use of the individual(s) or entity(ies) named above. If you are not the intended recipient (or authorized to receive this e-mail for the intended recipient), you may not use, copy, disclose or distribute to anyone this message or any information contained in this message. If you have received this electronic message in error, please notify us by replying to this e-mail. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] JFFS2 with NAND flash is very SLOW ...
On Tuesday 02 June 2009 15:02:17 Cote, Sylvain wrote: > > In my side: > > MTD0 (720kB): U-boot > > MTD1 (80kB) : env. Variables > > MTD2 (12MB) : kernel + initramfs > > MTD3 (50MB) : rootfs > > Maybe it will not help you but I have > > MTD0 (all the nand 256M) > MTD1 uboot+ embedded config 2M RAW > MTD2 1M JFFS2 > MTD5 config 5M JFFS2 > MTD3 Kernel + initramfs 12M JFFS2 > MTD4 KernelBKp 12M JFFS2 > MTD5 content 224M > > Scanning and fsload of the MTD3 partition take 3 seconds with 2009.03 > With 1.3.4 it was something like 6-10 seconds. But never 1 minute. I have > seen that when scanning the content partition of 224M. Parameters like I-cache and D-cache handling greatly effect this scan time. Some platforms have caches enabled others don't. This might explain some differences here. Best regards, 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] JFFS2 with NAND flash is very SLOW ...
Is it better to use or not D-cache and I-cache? Currently, in my config file, I have only #define CONFIG_CMD_CACHE What do I have to add? Thanks in advance for your help. Pierre -Message d'origine- De : u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] De la part de Stefan Roese Envoyé : mardi 2 juin 2009 15:18 À : u-boot@lists.denx.de Cc : Pierre Savary; Cote, Sylvain Objet : Re: [U-Boot] JFFS2 with NAND flash is very SLOW ... On Tuesday 02 June 2009 15:02:17 Cote, Sylvain wrote: > > In my side: > > MTD0 (720kB): U-boot > > MTD1 (80kB) : env. Variables > > MTD2 (12MB) : kernel + initramfs > > MTD3 (50MB) : rootfs > > Maybe it will not help you but I have > > MTD0 (all the nand 256M) > MTD1 uboot+ embedded config 2M RAW > MTD2 1M JFFS2 > MTD5 config 5M JFFS2 > MTD3 Kernel + initramfs 12M JFFS2 > MTD4 KernelBKp 12M JFFS2 > MTD5 content 224M > > Scanning and fsload of the MTD3 partition take 3 seconds with 2009.03 > With 1.3.4 it was something like 6-10 seconds. But never 1 minute. I have > seen that when scanning the content partition of 224M. Parameters like I-cache and D-cache handling greatly effect this scan time. Some platforms have caches enabled others don't. This might explain some differences here. Best regards, 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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] JFFS2 with NAND flash is very SLOW ...
On Tuesday 02 June 2009 15:23:57 Pierre Savary wrote: > Is it better to use or not D-cache and I-cache? Depends a bit on the "application". From my experience I-Cache is most important. But for memory intensive applications (JFFS2 might be such a beast) D-cache could be very helpful as well. Best is to have both enabled of course. > Currently, in my config file, I have only > #define CONFIG_CMD_CACHE > What do I have to add? Defining the cache commands doesn't insure that caches are really enabled. Some platforms don't support I- and/or D-cache in U-Boot. I can only speak for PPC4xx which has I-cache enabled and "usually" D-cache disabled (because of cache-coherency issues). This might be different on your platform. Again, just enabling the cache commands will most likely not help here. Best regards, 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] JFFS2 with NAND flash is very SLOW ...
In fact it is not better with this config: #define CONFIG_ICACHE_ON #define CONFIG_DCACHE_ON #define CONFIG_SYS_DCACHE_SIZE 32768 #define CONFIG_SYS_ICACHE_SIZE 32768 #define CONFIG_SYS_CACHELINE_SIZE 32 My architecture is arm926ejs and it seems that CACHE management is not implemented... I just measure a load of uImage (2MB) ... it takes more than 2 minutes :-( Pierre -Message d'origine- De : u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] De la part de Stefan Roese Envoyé : mardi 2 juin 2009 15:32 À : u-boot@lists.denx.de Cc : Pierre Savary; 'Cote, Sylvain' Objet : Re: [U-Boot] JFFS2 with NAND flash is very SLOW ... On Tuesday 02 June 2009 15:23:57 Pierre Savary wrote: > Is it better to use or not D-cache and I-cache? Depends a bit on the "application". From my experience I-Cache is most important. But for memory intensive applications (JFFS2 might be such a beast) D-cache could be very helpful as well. Best is to have both enabled of course. > Currently, in my config file, I have only > #define CONFIG_CMD_CACHE > What do I have to add? Defining the cache commands doesn't insure that caches are really enabled. Some platforms don't support I- and/or D-cache in U-Boot. I can only speak for PPC4xx which has I-cache enabled and "usually" D-cache disabled (because of cache-coherency issues). This might be different on your platform. Again, just enabling the cache commands will most likely not help here. Best regards, 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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] JFFS2 with NAND flash is very SLOW ...
On Tuesday 02 June 2009 15:56:25 Pierre Savary wrote: > In fact it is not better with this config: > #define CONFIG_ICACHE_ON > #define CONFIG_DCACHE_ON > #define CONFIG_SYS_DCACHE_SIZE 32768 > #define CONFIG_SYS_ICACHE_SIZE 32768 > #define CONFIG_SYS_CACHELINE_SIZE 32 > > My architecture is arm926ejs and it seems that CACHE management is not > implemented... > > I just measure a load of uImage (2MB) ... it takes more than 2 minutes :-( Yes, this is really slow. Jean-Christophe will be able to tell us if caches are supported on this platform in U-Boot. Best regards, 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] [PATCH 1/2] mpc512x: Fix PSC divisor calculation for baudrate setting
The wrong input frequency was used in serial_setbrg(). This patch fixes this by using ips_clk as input frequency for the PSC baudrate generator. Signed-off-by: Stefan Roese --- cpu/mpc512x/serial.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/cpu/mpc512x/serial.c b/cpu/mpc512x/serial.c index 16ce770..d39 100644 --- a/cpu/mpc512x/serial.c +++ b/cpu/mpc512x/serial.c @@ -167,7 +167,7 @@ void serial_setbrg (void) volatile psc512x_t *psc = (psc512x_t *) &im->psc[CONFIG_PSC_CONSOLE]; unsigned long baseclk, div; - baseclk = (gd->csb_clk + 8) / 16; + baseclk = (gd->ips_clk + 8) / 16; div = (baseclk + (gd->baudrate / 2)) / gd->baudrate; out_8(&psc->ctur, (div >> 8) & 0xFF); -- 1.6.2.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] mpc512x: Use serial_setbrg() in serial_init() to not duplicate the code
This patch removes the duplicated code for baudrate generator configuration
in the PSC serial_init() implementation by calling serial_setbrg() instead
of duplicating the code.
Signed-off-by: Stefan Roese
---
cpu/mpc512x/serial.c | 36 +++-
1 files changed, 15 insertions(+), 21 deletions(-)
diff --git a/cpu/mpc512x/serial.c b/cpu/mpc512x/serial.c
index d39..4fc4693 100644
--- a/cpu/mpc512x/serial.c
+++ b/cpu/mpc512x/serial.c
@@ -60,12 +60,24 @@ static void fifo_init (volatile psc512x_t *psc)
__asm__ volatile ("sync");
}
+void serial_setbrg(void)
+{
+ volatile immap_t *im = (immap_t *) CONFIG_SYS_IMMR;
+ volatile psc512x_t *psc = (psc512x_t *) &im->psc[CONFIG_PSC_CONSOLE];
+ unsigned long baseclk, div;
+
+ /* calculate dividor for setting PSC CTUR and CTLR registers */
+ baseclk = (gd->ips_clk + 8) / 16;
+ div = (baseclk + (gd->baudrate / 2)) / gd->baudrate;
+
+ out_8(&psc->ctur, (div >> 8) & 0xff);
+ out_8(&psc->ctlr, div & 0xff); /* set baudrate */
+}
+
int serial_init(void)
{
volatile immap_t *im = (immap_t *) CONFIG_SYS_IMMR;
volatile psc512x_t *psc = (psc512x_t *) &im->psc[CONFIG_PSC_CONSOLE];
- unsigned long baseclk;
- int div;
fifo_init (psc);
@@ -87,13 +99,8 @@ int serial_init(void)
/* now, mode register points to mr2 */
out_8(&psc->mode, PSC_MODE_1_STOPBIT);
- /* calculate dividor for setting PSC CTUR and CTLR registers */
- baseclk = (gd->ips_clk + 8) / 16;
- div = (baseclk + (gd->baudrate / 2)) / gd->baudrate;
-
- out_8(&psc->ctur, (div >> 8) & 0xff);
/* set baudrate */
- out_8(&psc->ctlr, div & 0xff);
+ serial_setbrg();
/* disable all interrupts */
out_be16(&psc->psc_imr, 0);
@@ -161,19 +168,6 @@ int serial_tstc (void)
return !(in_be32(&psc->rfstat) & PSC_FIFO_EMPTY);
}
-void serial_setbrg (void)
-{
- volatile immap_t *im = (immap_t *) CONFIG_SYS_IMMR;
- volatile psc512x_t *psc = (psc512x_t *) &im->psc[CONFIG_PSC_CONSOLE];
- unsigned long baseclk, div;
-
- baseclk = (gd->ips_clk + 8) / 16;
- div = (baseclk + (gd->baudrate / 2)) / gd->baudrate;
-
- out_8(&psc->ctur, (div >> 8) & 0xFF);
- out_8(&psc->ctlr, div & 0xff); /* set baudrate */
-}
-
void serial_setrts(int s)
{
volatile immap_t *im = (immap_t *) CONFIG_SYS_IMMR;
--
1.6.2.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM Cortex A8: Move OMAP3 specific reset handler to OMAP3 code
Dear Jean-Christophe, Jean-Christophe PLAGNIOL-VILLARD wrote: > On 17:56 Sun 31 May , Dirk Behme wrote: >> Dear Jean-Christophe, >> >> Jean-Christophe PLAGNIOL-VILLARD wrote: >>> On 09:30 Sat 30 May , Dirk Behme wrote: Reset is SoC specific and not ARM Cortex A8 generic. Move it from generic code to OMAP3 SoC specific file. CC: "Kim, Heung Jun" Signed-off-by: Dirk Behme --- This patches fixes the second issue found by riverful in http://lists.denx.de/pipermail/u-boot/2009-May/053433.html The first issue is fixed by http://lists.denx.de/pipermail/u-boot/2009-May/053444.html cpu/arm_cortexa8/omap3/lowlevel_init.S | 12 cpu/arm_cortexa8/start.S | 14 -- 2 files changed, 12 insertions(+), 14 deletions(-) Index: u-boot-arm/cpu/arm_cortexa8/omap3/lowlevel_init.S === --- u-boot-arm.orig/cpu/arm_cortexa8/omap3/lowlevel_init.S +++ u-boot-arm/cpu/arm_cortexa8/omap3/lowlevel_init.S @@ -181,6 +181,18 @@ lowlevel_init: /* back to arch calling code */ mov pc, lr +.global reset_cpu +reset_cpu: + ldr r1, rstctl @ get addr for global reset + @ reg + mov r3, #0x2@ full reset pll + mpu + str r3, [r1]@ force reset + mov r0, r0 +_loop_forever: + b _loop_forever +rstctl: + .word PRM_RSTCTRL + >>> please move this to reset.S other wise fine >> Most probably your idea is that each file should only contain >> functionality which fits 100% (120%?) what the file name implies (?). >> While from general point of view this is correct, it makes no sense to >> create new files again and again just to follow this rule. We already >> created a cache.c on your request, now you request a new file reset.S >> for ~5 assembly lines. This new file would contain more comments (e.g. >> GPL header) than useful code. > the idea is different here > I want to have only code in lowlevel_init.S that can be disable by > CONFIG_SKIP_LOWLEVEL_INIT and do it via Makefile Looking at recent OMAP3 lowlevel_init.S most probably some other stuff has to be moved to make this work, too. So for the moment, the cleanest way is to move above reset_cpu to low_levelinit.S. And then later, after thorough investigation and testing, move the stuff needed for your idea to an appropriate place. This move will be consistent then and will avoid polluting source tree with unnecessary files until then. So let's do it in two steps: a) Now, move reset_cpu to lowlevel_init.S so that Riverful can go on with his work b) Later, move everything necessary in one consistent patch set while you implement your "CONFIG_SKIP_LOWLEVEL_INIT via Makefile" idea Best regards Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] I wonder "---" in the patch file generated by the git-format-patch
> > > So, I get patch. But, this patch's form is different with you said. > First of all, the all comments is on the "---". > But, you said all comments must belong below the "---" like this messages. > : > http://lists.denx.de/pipermail/u-boot/2009-June/053535.html > It's different. > > What did I lose anything during the patching progress?? > Can you tell me what is wrong?? The comments you write in the commit message for your changes go above the "---". Those messages are meant to be included when the patch is applied, to let everyone know why you made the changes you made in your patch. However, if you want to say something in your email that isn't needed to understand the patch's purpose and effect, then you put it below the "---", and git will strip it out when the patch is applied. So you might create several versions of your patch over time, due to review, and on the final version. Here's a totally fake example: Fix a bug in the code that is here This patch fixes the bug that has this effect. Instead of doing the wrong thing, we do the right thing instead. Signed-off-by: My Name --- Changes in this version of the patch are: * Put these comments in the right place in the patch * Properly added a Signed-off-by line * Used better code style Hey, friends, I made the changes to my patch that you suggested. diff ---. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/6] mpc83xx: USB: Reorganized its support
> > > I freshly cloned the 'next' branch of u-boot-usb @ > http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot/u-boot-usb.git;a=shortlog > ;h=refs/heads/next and was able to apply all of the six patches > successfully. I am not sure what could be wrong at your end. Can you > post the errors which you see while doing git-am . > > Also, Andy (cc'ed) confirmed yesterday that he is going to pick the > above patches in his u-boot tree; so I am not sure in whose u-boot tree, > the patches are temporarily going to land. Well, the USB changes are under Remy's domain, so he has the ability to nack. I'm happy to apply them if they apply, as they mostly just change config headers. Andy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] JFFS2 with NAND flash is very SLOW ...
On 15:59 Tue 02 Jun , Stefan Roese wrote: > On Tuesday 02 June 2009 15:56:25 Pierre Savary wrote: > > In fact it is not better with this config: > > #define CONFIG_ICACHE_ON > > #define CONFIG_DCACHE_ON > > #define CONFIG_SYS_DCACHE_SIZE 32768 > > #define CONFIG_SYS_ICACHE_SIZE 32768 > > #define CONFIG_SYS_CACHELINE_SIZE 32 > > > > My architecture is arm926ejs and it seems that CACHE management is not > > implemented... > > > > I just measure a load of uImage (2MB) ... it takes more than 2 minutes :-( > > Yes, this is really slow. Jean-Christophe will be able to tell us if caches > are supported on this platform in U-Boot. I've not yet find time to implement the MMU support for arm (needed for D-Cache support), I've plan to add it for the next release (not for this next merge window) I-Cache is supported but 2 mins is really slow, could show us your code? Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] JFFS2 with NAND flash is very SLOW ...
Which source code? I use the 2009.03 version without modification. This is my config file: [...] #define CONFIG_CMD_NAND #define CONFIG_SYS_MAX_FLASH_BANKS 1 #define CONFIG_SYS_MAX_NAND_DEVICE 1 #define CONFIG_SYS_NAND_BASE0x2002 #define NAND_MAX_CHIPS 1 #define CONFIG_ENV_IS_IN_NAND [...] #define CONFIG_CMD_JFFS2 [...] #define CONFIG_JFFS2_NAND #undef CONFIG_JFFS2_CMDLINE #define CONFIG_JFFS2_DEV"nand0" #define CONFIG_JFFS2_PART_SIZE 0x00C0 #define CONFIG_JFFS2_PART_OFFSET0x000C8000 [...] #define CONFIG_ICACHE_ON #define CONFIG_DCACHE_ON #define CONFIG_SYS_DCACHE_SIZE 32768 #define CONFIG_SYS_ICACHE_SIZE 32768 #define CONFIG_SYS_CACHELINE_SIZE 32 [...] And in fact it is better with I-Cache enabled. I carried out more precise measurements and I obtain: 1min45 without I-cache and 40sec with I-cache. It is better but not enough... Thanks for your help. Best Regards, Pierre -Message d'origine- De : u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] De la part de Jean-Christophe PLAGNIOL-VILLARD Envoyé : mardi 2 juin 2009 17:06 À : Stefan Roese Cc : Pierre Savary; 'Cote, Sylvain'; u-boot@lists.denx.de Objet : Re: [U-Boot] JFFS2 with NAND flash is very SLOW ... On 15:59 Tue 02 Jun , Stefan Roese wrote: > On Tuesday 02 June 2009 15:56:25 Pierre Savary wrote: > > In fact it is not better with this config: > > #define CONFIG_ICACHE_ON > > #define CONFIG_DCACHE_ON > > #define CONFIG_SYS_DCACHE_SIZE 32768 > > #define CONFIG_SYS_ICACHE_SIZE 32768 > > #define CONFIG_SYS_CACHELINE_SIZE 32 > > > > My architecture is arm926ejs and it seems that CACHE management is not > > implemented... > > > > I just measure a load of uImage (2MB) ... it takes more than 2 minutes :-( > > Yes, this is really slow. Jean-Christophe will be able to tell us if caches > are supported on this platform in U-Boot. I've not yet find time to implement the MMU support for arm (needed for D-Cache support), I've plan to add it for the next release (not for this next merge window) I-Cache is supported but 2 mins is really slow, could show us your code? Best Regards, J. ___ 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 1/2] Create the S5PC100 SoC code under the cpu/arm_cortesa8/
Hi Riverful, Kim, Heung Jun wrote: > Signed-off-by: HeungJun, Kim > > --- > > This patch is the new processor - S5PC100's SoC code & headers. > This patch consists of 2 files. > > The First file is to create the new SoC code related with S5PC100 > application processor. > It's located in ther cpu/arm_cortesa8/s5pc100. > > The Second file is to create the new SoC header related with S5PC100 > application processor. > It's located in ther include/asm-arm/s5pc100. > > This file is the First. > > cpu/arm_cortexa8/s5pc100/Makefile | 48 +++ > cpu/arm_cortexa8/s5pc100/config.mk| 36 ++ > cpu/arm_cortexa8/s5pc100/cpu_init.S | 196 + > cpu/arm_cortexa8/s5pc100/interrupts.c | 218 > + > cpu/arm_cortexa8/s5pc100/speed.c | 159 > 5 files changed, 657 insertions(+), 0 deletions(-) > create mode 100644 cpu/arm_cortexa8/s5pc100/Makefile > create mode 100644 cpu/arm_cortexa8/s5pc100/config.mk > create mode 100644 cpu/arm_cortexa8/s5pc100/cpu_init.S > create mode 100644 cpu/arm_cortexa8/s5pc100/interrupts.c > create mode 100644 cpu/arm_cortexa8/s5pc100/speed.c ... Some general comments on this and the second patch: Can you try to format your patch series that it looks like something [PATCH 0/2] ARM Cortex A8: Add new target S5PC100 SoC [PATCH 1/2] ARM Cortex A8: S5PC100: Add CPU files [PATCH 2/2] ARM Cortex A8: S5PC100: Add header files With Patch 0/2 containing *no* patch code, just the explanation: -- cut -- This patch series adds the new ARM Cortex A8 based S5PC100's SoC code & headers. This patch consists of 2 files. The First file is to create the new SoC code related with S5PC100 application processor. It's located in ther cpu/arm_cortesa8/s5pc100. The Second file is to create the new SoC header related with S5PC100 application processor. It's located in ther include/asm-arm/s5pc100. This series depends on http://lists.denx.de/pipermail/u-boot/2009-June/053623.html and http://lists.denx.de/pipermail/u-boot/2009-May/053490.html -- cut -- Then with Patch 1/2: -- cut -- Add CPU support for S5PC100. Signed-off-by: HeungJun, Kim --- cpu/arm_cortexa8/s5pc100/Makefile | 48 +++ cpu/arm_cortexa8/s5pc100/config.mk| 36 ++ ... -- cut -- (Note the explanation *before* the Signed-off-by and the ---) Then with patch 2/2: -- cut -- Add S5PC100 header files. Signed-off-by: HeungJun, Kim --- include/asm-arm/arch-s5pc100/clock.h | 137 +++ include/asm-arm/arch-s5pc100/cpu.h | 292 +++ ... -- cut -- Best regards Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] Create the S5PC100 SoC header under the include/asm-arm/arch-s5pc100
Kim, Heung Jun wrote: > Signed-off-by: HeungJun, Kim > > --- > > This patch is the new processor - S5PC100's SoC code & headers. > This patch consists of 2 files. > > The First file is to create the new SoC code related with S5PC100 > application processor. > It's located in ther cpu/arm_cortesa8/s5pc100. > > The Second file is to create the new SoC header related with S5PC100 > application processor. > It's located in ther include/asm-arm/s5pc100. > > This file is the Second. I wonder if there is any patch missing here? Is it correct that this series stops after 2 patches? Shouldn't there be at least something added to board directory? And I miss a config file to be able to compile this stuff. Best regards Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mmc: fix SD card SCR register decoding on little endian systems
Rabin Vincent's fix for little endian systems fixes only the issues
regarding responses received on the command line.
However the SD card's SCR register is received on the DAT0 line
- therefore it must be handled in an endian independent way.
This is an addendum to "[PATCH 4/5] mmc: fix response decoding on little
endian" from rabin at rab.in.
Signed-off-by: Ulrich Herrmann
Index: include/mmc.h
===
--- a/include/mmc.h
+++ b/include/mmc.h
@@ -45,7 +45,7 @@
#define MMC_MODE_4BIT 0x100
#define MMC_MODE_8BIT 0x200
-#define SD_DATA_4BIT 0x0004
+#define SD_DATA_4BIT 0x04
#define IS_SD(x) (mmc->version & SD_VERSION_SD)
Index: drivers/mmc/mmc.c
===
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -490,7 +490,7 @@
mmc->scr[0] = scr[0];
mmc->scr[1] = scr[1];
- switch ((mmc->scr[0] >> 24) & 0xf) {
+ switch char*)mmc->scr)[0]) & 0xf) {
case 0:
mmc->version = SD_VERSION_1_0;
break;
@@ -522,7 +522,7 @@
break;
}
- if (mmc->scr[0] & SD_DATA_4BIT)
+ if (((char*)mmc->scr)[1] & SD_DATA_4BIT)
mmc->card_caps |= MMC_MODE_4BIT;
/* If high-speed isn't supported, we return */
This message may contain confidential and/or privileged information intended
only for the addressee.
If you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose or take any action based
on this message or any information herein. If you have received this
message in error, please advise the sender immediately by reply e-mail and
delete this message. Any views expressed in this message are those of the
individual sender and may not necessarily reflect the
opinions of austriamicrosystems AG.
Diese E-Mail enthaelt moeglicherweise vertrauliche und/oder rechtlich
geschuetzte Informationen.
Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtuemlich
erhalten haben, informieren Sie bitte sofort den Absender und loeschen Sie
diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser
Mail ist nicht gestattet. Etwaige in dieser E-mail geaeusserte Ansichten und
Meinungen stammen vom Versender dieser Nachricht und muessen nicht
notwendigerweise mit den Meinungen und Ansichten von austriamicrosystems AG
uebereinstimmen.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Assigned a static SMI address to all UECs TBIPA address.
It is set to 0x1F by default and can be overwritten on the board
header file by defining CONFIG_UTBIPAR_INIT_TBIPA. This allows
the CPU to simply "reserve" one SMI address instead of using
a different one for each UEC.
---
drivers/qe/uec.c | 17 +
1 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/qe/uec.c b/drivers/qe/uec.c
index 91d1182..a8a229f 100644
--- a/drivers/qe/uec.c
+++ b/drivers/qe/uec.c
@@ -31,6 +31,11 @@
#include "uec_phy.h"
#include "miiphy.h"
+/* Default UTBIPAR SMI address */
+#ifndef CONFIG_UTBIPAR_INIT_TBIPA
+#define CONFIG_UTBIPAR_INIT_TBIPA 0x1F
+#endif
+
#ifdef CONFIG_UEC_ETH1
static uec_info_t eth1_uec_info = {
.uf_info= {
@@ -1179,15 +1184,11 @@ static int uec_startup(uec_private_t *uec)
utbipar = in_be32(&uec_regs->utbipar);
utbipar &= ~UTBIPAR_PHY_ADDRESS_MASK;
enet_interface = uec->uec_info->enet_interface;
- if (enet_interface == ENET_1000_TBI ||
-enet_interface == ENET_1000_RTBI) {
- utbipar |= (uec_info->phy_address + uec_info->uf_info.ucc_num)
-<< UTBIPAR_PHY_ADDRESS_SHIFT;
- } else {
- utbipar |= (0x10 + uec_info->uf_info.ucc_num)
-<< UTBIPAR_PHY_ADDRESS_SHIFT;
- }
+ /* Initialize UTBIPAR address to CONFIG_UTBIPAR_INIT_TBIPA for ALL UEC.
+* This frees up the remaining SMI addresses for use.
+*/
+ utbipar |= CONFIG_UTBIPAR_INIT_TBIPA << UTBIPAR_PHY_ADDRESS_SHIFT;
out_be32(&uec_regs->utbipar, utbipar);
/* Allocate Tx BDs */
--
1.6.2.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Kconfig menu layout (multiple ways to show the same Kconfig configs?)
On May 1, 2009, at 6:47 AM, Sam Ravnborg wrote: > On Wed, Apr 22, 2009 at 07:44:48AM -0500, Kumar Gala wrote: >> >> On Apr 21, 2009, at 3:52 PM, Wolfgang Denk wrote: >> >>> Dear Kumar Gala, >>> >>> In message <93A8F58D-8C13-4F72-AFF3- >>> cf4fdf9a3...@kernel.crashing.org> you wrote: > In my experience, I tend to search for board names first. So back to the root of my question, do we just have one really long list of board names? >>> >>> I'm not an expert for the capabilities of Kconfig, but one looong >>> list >>> with hundrets of entries clearly makes no sense. We obviously need >>> sum >>> grouping / structuring. >>> >>> IMHO there should be several options: >>> >>> - for those who look for a board name, we should support this, >>> probably wih an initial selection by the first letter (case >>> insensitive) of the board name. >>> >>> like this: => board name => M => MPC837XERDB >>> >>> - alternatively, it should be possible to restrict the choice by >>> selecting first processor architecture (ARM, PowerPC, MIPS, ...), >>> then CPU (family) name, then board names. >>> >>> like this: => Architecture => PPC => MPC83xx => MPC837XERDB >> >> Sam, >> >> We are looking at moving u-boot to use Kconfig and was wondering if >> you could possible tell us if its possible to represent the same >> Kconfig 'config' options via two different menu schemes. We have a >> list of boards that will be 'config' options. We'd like to have it >> in >> one 'menu' that is just a long list of boards. The other would be a >> smaller subset that you "filter" based on selecting an Arch & >> Subarch. >> >> is something like this possible? > > Hi Kumar. > > Was my input useable or just pure rubbish? Its usable.. one question I had was if you ever gave thought to having a 'config' type that was only for internal dependencies and didn't show up in the resulting .config. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] TSEC ethernet controller problems (crc errors / corruption)
Hello U-Boot users,
I've been working on a custom board, based heavily on the Freescale
MPC8349EMDS board. The only major difference is that the board has some
FPGAs connected to the local bus.
I've found that the TSEC / gianfar ethernet does not work for me in
1000mbit mode. I constantly get "got error 4" from U-Boot, which means
that a CRC error was detected by the TSEC controller.
I have tried running the TSEC in 100mbit mode, without any problems. I
can tftp as much data as I want in U-Boot, and I've transferred many,
many gigabytes without issue in Linux. The problem is only with 1000mbit
mode.
I initially suspected problems with the PHY, a Marvell 88E. To
diganose the problem, I set the PHY into loopback mode, then connected
my logic analyzer to the PHY's RX lines. This removes the external
network from the equation: I don't even have an ethernet cable
connected.
The logic analyzer traces show the correct, expected packet data coming
from the PHY. By the time the TSEC copies the data into a buffer
descriptor, the packet data has been corrupted. The problem is extra or
missing bytes in the packet data. I have added some code to dump the
packet contents on CRC error, and what I see in memory is not what the
PHY sent.
The corruption is not at a consistent offset in the packet. The number
of extra or missing bytes is not always the same.
The extra bytes that show up in the packet data seem like a FIFO issue
to me. It is as if the internal FIFO reported that more data was
available before the data was actually present. Something like that.
For reference, here is what a memory dump of a good packet looks like.
It has a length of 64 bytes. I have dumped 16 bytes past the end of the
packet data.
0fffcbe0: ff ff ff ff ff ff ae dc 30 45 e8 3a 08 06 00 010E.:
0fffcbf0: 08 00 06 04 00 01 ae dc 30 45 e8 3a c0 a8 11 450E.:...E
0fffcc00: 00 00 00 00 00 00 c0 a8 11 39 00 00 00 00 00 00.9..
0fffcc10: 00 00 00 00 00 00 00 00 00 00 00 00 2c d1 57 03,.W.
0fffcc20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
And this is what a bad packet looks like in memory. The length was
reported by the TSEC as 64 bytes, but it was flagged as having a CRC
error. Notice the extra bytes starting at 0x0fffcc0c, "copied" from 16
bytes earlier in the packet. The CRC is shifted 4 bytes in the packet
due to the extra bytes.
0fffcbe0: ff ff ff ff ff ff ae dc 30 45 e8 3a 08 06 00 010E.:
0fffcbf0: 08 00 06 04 00 01 ae dc 30 45 e8 3a c0 a8 11 450E.:...E
0fffcc00: 00 00 00 00 00 00 c0 a8 11 39 00 00 c0 a8 11 45.9.E
0fffcc10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0fffcc20: 2c d1 57 03 00 00 00 00 00 00 00 00 00 00 00 00,.W.
I have been running U-Boot and Linux on this board for >6 months. I've
run plenty of stress tests, and I've been doing lots of work with the
DMA controller. I've stressed the memory pretty hard, and I'm fairly
confident that it is not a problem with RAM. The board has been
perfectly stable.
Other solutions I have tried, without any effect:
* slowing down the core frequency from 528 -> 264 MHz
* slowing down the RAM frequency from 266 -> 200 MHz
I am unable to reproduce the corruption on my MPC8349EMDS eval board,
but I'm running out of ideas to try and find the source of this problem.
Has anyone seen anything like this before?
Thanks for your help,
Ira
PS - Below is the patch of the debugging code I've added.
diff --git a/drivers/net/tsec.c b/drivers/net/tsec.c
index 399116f..2f8f1bc 100644
--- a/drivers/net/tsec.c
+++ b/drivers/net/tsec.c
@@ -214,7 +214,9 @@ int tsec_init(struct eth_device *dev, bd_t * bd)
startup_tsec(dev);
/* If there's no link, fail */
- return (priv->link ? 0 : -1);
+ printf("LINK: %d\n", priv->link);
+ return 0;
+ //return (priv->link ? 0 : -1);
}
/* Writes the given phy's reg with value, using the specified MDIO regs */
@@ -928,22 +930,44 @@ static int tsec_send(struct eth_device *dev, volatile
void *packet, int length)
return result;
}
+static unsigned char MYPACKET[4096];
+
static int tsec_recv(struct eth_device *dev)
{
int length;
struct tsec_private *priv = (struct tsec_private *)dev->priv;
volatile tsec_t *regs = priv->regs;
+ u32 hwcrc, swcrc, cpcrc, rxaddr;
while (!(rtx.rxbd[rxIdx].status & RXBD_EMPTY)) {
length = rtx.rxbd[rxIdx].length;
+ hwcrc = *(u32 *)(NetRxPackets[rxIdx] + length - 4);
+ memcpy(MYPACKET, NetRxPackets[rxIdx], length + 16);
+ swcrc = crc32(0, MYPACKET, length - 4);
+ swcrc = swab32(swcrc);
+ cpcrc = *(u32 *)(MYPACKET + length - 4);
+
+ printf("CRC HW 0x%.8x SW 0x%.8x CP 0x%.8x IEVENT 0x%.8x MACCFG1
0x%.8x\n",
+ hwcrc, swcrc, cpcrc, regs->ievent,
regs->ma
Re: [U-Boot] TSEC ethernet controller problems (crc errors / corruption)
> I am unable to reproduce the corruption on my MPC8349EMDS eval board, > but I'm running out of ideas to try and find the source of this problem. One more piece of info: the MPC8349E-MDS board contains the MPC8349E processor, whereas our board contains the MPC8349EA (silicon v 3.1) processor. We did have a couple of MPC8349EA-MDS boards, however, the Xilinx CPLD on both boards spontaneously destructed (the CPLD sticky labels melted!). We can try putting the MPC8349EA processor from one of the dead boards into the MPC8349E-MDS board socket - I believe this is ok - feel free to warn us that its not :) Cheers, Dave ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] TSEC ethernet controller problems (crc errors / corruption)
On Tue, 2009-06-02 at 09:42 -0700, David Hawkins wrote: > > I am unable to reproduce the corruption on my MPC8349EMDS eval board, > > but I'm running out of ideas to try and find the source of this problem. > > One more piece of info: the MPC8349E-MDS board contains the > MPC8349E processor, whereas our board contains the MPC8349EA > (silicon v 3.1) processor. We did have a couple of MPC8349EA-MDS > boards, however, the Xilinx CPLD on both boards spontaneously > destructed (the CPLD sticky labels melted!). > > We can try putting the MPC8349EA processor from one of the > dead boards into the MPC8349E-MDS board socket - I believe > this is ok - feel free to warn us that its not :) What interface are you using between the MAC and PHY? I saw somewhat similar weirdness at gigabit on a board when using RGMII and the clock delays in the PHY and PCB didn't match up correctly (Section 5.12.2 from the 88e manual). If you aren't using RGMII, this wouldn't be your issue though... Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] TSEC ethernet controller problems (crc errors / corruption)
Hi Peter, >>> I am unable to reproduce the corruption on my MPC8349EMDS eval board, >>> but I'm running out of ideas to try and find the source of this problem. >> One more piece of info: the MPC8349E-MDS board contains the >> MPC8349E processor, whereas our board contains the MPC8349EA >> (silicon v 3.1) processor. We did have a couple of MPC8349EA-MDS >> boards, however, the Xilinx CPLD on both boards spontaneously >> destructed (the CPLD sticky labels melted!). >> >> We can try putting the MPC8349EA processor from one of the >> dead boards into the MPC8349E-MDS board socket - I believe >> this is ok - feel free to warn us that its not :) > > What interface are you using between the MAC and PHY? I saw somewhat > similar weirdness at gigabit on a board when using RGMII and the clock > delays in the PHY and PCB didn't match up correctly (Section 5.12.2 from > the 88e manual). If you aren't using RGMII, this wouldn't be your > issue though... The default is to use GMII. Ira reconfigured the interface to RGMII after boot, and saw similar errors to those he was getting in GMII mode. Probing the PHY-to-MAC path shows the data we expect, so the error seems to be internal to the processor ... The signal integrity on the board is good, we compared the timing between our board and the Freescale MDS board, and it all looks very similar. Cheers, Dave ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] TSEC ethernet controller problems (crc errors / corruption)
On Tue, Jun 02, 2009 at 12:35:14PM -0500, Peter Tyser wrote: > On Tue, 2009-06-02 at 09:42 -0700, David Hawkins wrote: > > > I am unable to reproduce the corruption on my MPC8349EMDS eval board, > > > but I'm running out of ideas to try and find the source of this problem. > > > > One more piece of info: the MPC8349E-MDS board contains the > > MPC8349E processor, whereas our board contains the MPC8349EA > > (silicon v 3.1) processor. We did have a couple of MPC8349EA-MDS > > boards, however, the Xilinx CPLD on both boards spontaneously > > destructed (the CPLD sticky labels melted!). > > > > We can try putting the MPC8349EA processor from one of the > > dead boards into the MPC8349E-MDS board socket - I believe > > this is ok - feel free to warn us that its not :) > > What interface are you using between the MAC and PHY? I saw somewhat > similar weirdness at gigabit on a board when using RGMII and the clock > delays in the PHY and PCB didn't match up correctly (Section 5.12.2 from > the 88e manual). If you aren't using RGMII, this wouldn't be your > issue though... > We're using GMII, exactly the same as the Freescale eval board. I did a very quick test with the board in RGMII mode as well, and the board behaved in exactly the same way it does in GMII mode. Thanks, Ira ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/6] mpc83xx: USB: Reorganized its support
Hello Vivek, > I freshly cloned the 'next' branch of u-boot-usb @ > http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot/u-boot-usb.git;a=shortlog > ;h=refs/heads/next and was able to apply all of the six patches > successfully. I am not sure what could be wrong at your end. Can you > post the errors which you see while doing git-am . Hmm,strange, now they apply... I do not know what went wrong yesterday either... > Also, Andy (cc'ed) confirmed yesterday that he is going to pick the > above patches in his u-boot tree; so I am not sure in whose u-boot tree, > the patches are temporarily going to land. Well, it is USB driver related, so IMO it belongs in the u-boot-usb tree... So, they are now applied to the u-boot-usb 'next' branch. Kind regards, Remy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] TSEC ethernet controller problems (crc errors / corruption)
On Tue, 2 Jun 2009 11:17:26 -0700 Ira Snyder wrote: > On Tue, Jun 02, 2009 at 12:35:14PM -0500, Peter Tyser wrote: > > On Tue, 2009-06-02 at 09:42 -0700, David Hawkins wrote: > > > > I am unable to reproduce the corruption on my MPC8349EMDS eval board, > > > > but I'm running out of ideas to try and find the source of this problem. > > > > > > One more piece of info: the MPC8349E-MDS board contains the > > > MPC8349E processor, whereas our board contains the MPC8349EA > > > (silicon v 3.1) processor. We did have a couple of MPC8349EA-MDS > > > boards, however, the Xilinx CPLD on both boards spontaneously > > > destructed (the CPLD sticky labels melted!). > > > > > > We can try putting the MPC8349EA processor from one of the > > > dead boards into the MPC8349E-MDS board socket - I believe > > > this is ok - feel free to warn us that its not :) the 8349E rev.1.x had a TSEC FIFO erratum, and I've put an 8360EA chip on an 8360E-MDS board and it came up fine (apart from the PHY timing issues that plagued the 8360), so it would be good to try. > > What interface are you using between the MAC and PHY? I saw somewhat > > similar weirdness at gigabit on a board when using RGMII and the clock > > delays in the PHY and PCB didn't match up correctly (Section 5.12.2 from > > the 88e manual). If you aren't using RGMII, this wouldn't be your > > issue though... > > > > We're using GMII, exactly the same as the Freescale eval board. I did a > very quick test with the board in RGMII mode as well, and the board > behaved in exactly the same way it does in GMII mode. all I can say is git grep R_TSEC for more TSEC frequency & timing knobs... hth, Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MPC8313ERDB board reset problem
On Tue, 2 Jun 2009 14:34:38 +0530 Deepak Gopalakrishnan wrote: > Hi im using mpc8313erdb board. and i have modified the u-boot 1.3.0 code > to suit my needs. But the problem is that now as soon as power up the > board, the initial msgs are dumped on the telnet...and then as soon as > the prompt is displayedit resetsand keeps on doing the same... > the thing is i dont know what change has caused thisit would be of > great help if anyone can guide me identify wat component have i messed > up... this could be anything including bad memory controller configuration. Exactly how far does the prompt get? Do you have a JTAG debugger? Does the same thing happen with the latest & greatest u-boot on git.denx.de? Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] TSEC ethernet controller problems (crc errors / corruption)
Dear Ira Snyder, In message <20090602162757.ga6...@ovro.caltech.edu> you wrote: > > I've been working on a custom board, based heavily on the Freescale > MPC8349EMDS board. The only major difference is that the board has some > FPGAs connected to the local bus. > > I've found that the TSEC / gianfar ethernet does not work for me in > 1000mbit mode. I constantly get "got error 4" from U-Boot, which means > that a CRC error was detected by the TSEC controller. > > I have tried running the TSEC in 100mbit mode, without any problems. I > can tftp as much data as I want in U-Boot, and I've transferred many, > many gigabytes without issue in Linux. The problem is only with 1000mbit > mode. I read that the same problem happens in Linux when running at 1000mbit. Is this understanding correct? Does running with root file system mounted over NFS work on this board? Does it work at 1000mbit, too? Did you try and re-check the memory controller initialization? 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 "Spock, did you see the looks on their faces?" "Yes, Captain, a sort of vacant contentment." ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] TSEC ethernet controller problems (crc errors / corruption)
Hi Wolfgang, >> I've been working on a custom board, based heavily on the Freescale >> MPC8349EMDS board. The only major difference is that the board has some >> FPGAs connected to the local bus. >> >> I've found that the TSEC / gianfar ethernet does not work for me in >> 1000mbit mode. I constantly get "got error 4" from U-Boot, which means >> that a CRC error was detected by the TSEC controller. >> >> I have tried running the TSEC in 100mbit mode, without any problems. I >> can tftp as much data as I want in U-Boot, and I've transferred many, >> many gigabytes without issue in Linux. The problem is only with 1000mbit >> mode. > > I read that the same problem happens in Linux when running at > 1000mbit. Is this understanding correct? > > Does running with root file system mounted over NFS work on this > board? Does it work at 1000mbit, too? I'll let Ira answer those questions. > Did you try and re-check the memory controller initialization? The memory is DDR1 (2.5V) configured with ECC enabled. The DDR control clock was moved to various settings to see how much timing margin there was, and the central setting was selected (there appears to be good margin). I'm not sure that a TSEC induced memory burst would be any different than a DMA induced memory, so if we were going to see errors, I would have expected to see them during DMA testing. The strange thing about the patterns Ira is seeing is that the erroneous data sometimes matches data that occurred much earlier in a packet, not the last data on the DDR bus. This has a symptom like a FIFO address wrap-around where the FIFO erroneously indicates it has valid data, so the FIFO reader reads the stale data, and writes it to DDR. Ira will play with some of the TSEC settings and see if he can change the symptom. Thanks for the suggestions! Cheers, Dave ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] USB gadget interface from cdc branch into mainline
Hello, 2009/6/2 Raghu : > On Mon, Jun 1, 2009 at 10:38 AM, Remy Bohmer wrote: >> Yeah, I planned it for the next release. > Is it going to be u-boot-2009.06? > I am interested in supporting OMAP3 musb drivers with this new interface. 2009.06 is the current release. This change is too intrusive to integrate it at this stage in the current release. So, it will go in the next. If you have patches for OMAP3 I am happy to queue them up in the cdc branch, so that they will move to ML when the merge window is open. Kind regards, Remy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Enable display CPU-Info for at91sam9261
Hello, >> > @@ -45,6 +45,8 @@ >> > #define CONFIG_SKIP_LOWLEVEL_INIT >> > #define CONFIG_SKIP_RELOCATE_UBOOT >> > >> > +#define CONFIG_DISPLAY_CPUINFO 1 >> >> For homogeneity reasons, since this is a generic AT91 config option, I think >> it makes sense to define this by default for all the AT91 boards - or not >> define it at all. Your pick. Well, I only have the at91sam9261ek board, and as such it is the only one I can test. I do not prefer enabling things for boards I cannot test. Once the framework is there it can be enabled, if desired. > for the Atmel's ref boards maybe but for other boards we need to let this > choice to each board Maintainer I agree on that. Kind Regards, Remy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] JFFS2 + cache coherency
My system is based on MPc8544. I am loading a small standalone program (2KB) from the JFFS2 partition (NOR flash) My program crashes while it does not crash if loaded from a tftp server. After investifgation using Codewarrior I noticed that there is a difference between the memory and Dcache content. Some number of words (8 = cache line)) are all zero in Dcache. Hence when jumping the program crashes as I guess the instruction cache is picking the instructions from the Dcache. When the program is loaded from a tftp server both the cache (in copyback mode) and DDR are set with the same data and therefore the program works. When loaded from a JFFS2 partition, the data are loaded to inode buffer (flash to memory with cache inhibited) in memory and then (mem)copied to the destination address (memory to memory). (Hope I got this right). This is why the cache/memory is not in sync. The problem does not exist when the cache is write-through. Also the Freescale documentation on cache cohenrency specifies that software should make sure that the cache/memory are synchronized before jumping to a new location. Hence, I think the cache should be flushed in or after do_jffs2_fsload. A call to flush_dcache(); fixes the problem. Let me know if you think I am right regarding this issue. cheers, Renaud ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] TSEC ethernet controller problems (crc errors / corruption)
On Tue, Jun 02, 2009 at 08:50:04PM +0200, Wolfgang Denk wrote: > Dear Ira Snyder, > > In message <20090602162757.ga6...@ovro.caltech.edu> you wrote: > > > > I've been working on a custom board, based heavily on the Freescale > > MPC8349EMDS board. The only major difference is that the board has some > > FPGAs connected to the local bus. > > > > I've found that the TSEC / gianfar ethernet does not work for me in > > 1000mbit mode. I constantly get "got error 4" from U-Boot, which means > > that a CRC error was detected by the TSEC controller. > > > > I have tried running the TSEC in 100mbit mode, without any problems. I > > can tftp as much data as I want in U-Boot, and I've transferred many, > > many gigabytes without issue in Linux. The problem is only with 1000mbit > > mode. > > I read that the same problem happens in Linux when running at > 1000mbit. Is this understanding correct? > Yes. Both U-Boot and Linux exhibit problems at 1000mbit. Both work without errors at 100mbit. > Does running with root file system mounted over NFS work on this > board? Does it work at 1000mbit, too? > 100mbit: yes 1000mbit: no If I boot up the board with the ethernet cable in a 100mbit port, then move the cable to a 1000mbit port, the NFS code says "server not responding" in <10 seconds. > Did you try and re-check the memory controller initialization? > See Dave's comments in reply your message. I've just re-checked that the memory configuration I expect is in the correct registers. Thanks, Ira ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] update nand.h to support address more than 0x80000000
On Tue, Jun 02, 2009 at 07:27:01PM +0800, adrian wen wrote: > Hi all, > > I found a bug in nand.h which prevent UBOOT to supprt large NAND chip. > > The bug description as below: > In the original implementation, we use a wrapper function in > nand.h to facilitate nand_base function usage in other files, > like cmd_nand.c, nand_util.c etc. > > However, the wrapper in nand.h is using off_t which is long type. > If we pass a address like 0x8000, which is allowed by nand_base.c, > the wrapper would recognize it as a negative num. So we would get a > huge num when this parameter get into nand_base.c > > Fix it by replacing off_t to loff_t type. > > Signed-off-by: Lei Wen A substantially similar patch was posted here: http://lists.denx.de/pipermail/u-boot/2009-May/052847.html I'm fine with this change, but it should also handle large erases. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] TSEC ethernet controller problems (crc errors/ corruption)
What is the ACR register settings? What is the freq of core/csb/DDR and TSEC block? Thanks, Dave ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] TSEC ethernet controller problems (crc errors/ corruption)
> What is the ACR register settings? > What is the freq of core/csb/DDR and TSEC block? And what is the SICRH[30-31]? Did you have the matching settings for GMII with 3.3V? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/8] Add simple hwconfig infrastructure
On Wed, Apr 29, 2009 at 4:50 PM, Anton Vorontsov wrote: > This patch implements simple hwconfig infrastructure: an > interface for software knobs to control a hardware. > > This is very simple implementation, i.e. it is implemented > via `hwconfig' environment variable. Later we could write > some "hwconfig " commands, ncurses > interface for Award BIOS-like interface, and frame-buffer > interface for AMI GUI[1] BIOS-like interface with mouse > support[2]. ...Any updates on this? It looks like your eSDHC patches rely on it, so I can't apply any of these 8 patches until this one passes. :) Andy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] TSEC ethernet controller problems (crc errors/ corruption)
On Wed, Jun 03, 2009 at 04:44:54AM +0800, Liu Dave-R63238 wrote: > > What is the ACR register settings? => md e800 1 e800: 00030300 > > What is the freq of core/csb/DDR and TSEC block? According to U-Boot's clocks command: => clocks Clock configuration: Core:533.333 MHz Coherent System Bus: 266.667 MHz Local Bus Controller:266.667 MHz Local Bus: 33.333 MHz DDR: 266.667 MHz SEC: 88.889 MHz I2C1:266.667 MHz I2C2:266.667 MHz TSEC1: 266.667 MHz TSEC2: 266.667 MHz USB DR: 88.889 MHz USB MPH: 88.889 MHz > > And what is the SICRH[30-31]? > Did you have the matching settings for GMII with 3.3V? > => md e118 1 e118: 0002 This looks wrong. The MPC8349EMDS board has the exact same setting in that register. Writing 0x0 to the SICRH register did not cause the problem to go away. I'll go find out why this is set in the MPC8349EMDS configuration as well. It shouldn't be. Thanks, Ira ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] 85xx: Fix the clock adjust of mpc8569mds board
On Fri, Mar 27, 2009 at 1:32 AM, Dave Liu wrote: > Currently the clk_adj is 6 (3/4 cycle), The settings will cause > the DDR controller hang at the data init. Change the clk_adj > from 6 to 4 (1/2 cycle), make the memory system stable. > > Signed-off-by: Dave Liu Applied to HEAD, thanks! Andy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] 85xx: Add P2020DS support
On Fri, Apr 3, 2009 at 3:36 PM, Kumar Gala wrote: > From: Srikanth Srinivasan > > The patch adds support for P2020DS reference platform. > DDR3 interface uses hard-coded initialization rather than SPD > for now and was tested at 667Mhz. Some PIXIS register > definitions and associated code sections need to be fixed. > TSEC1/2/3, NOR flash, MAC/SYS ID EEPROM, PCIE1/2/3 are all > tested under u-boot. > > Signed-off-by: Srikanth Srinivasan > Signed-off-by: Travis Wheatley > Signed-off-by: Kumar Gala Applied to HEAD, thanks! Andy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] PATCH: bugfix for reading maximum TLB size on mpc85xx
On Thu, May 14, 2009 at 1:08 PM, Kumar Gala wrote: > > On May 14, 2009, at 12:38 PM, Fredrik Arnerup wrote: > > > The MAXSIZE field in the TLB1CFG register is 4 bits, not 8 bits. > > This made setup_ddr_tlbs() try to set up a TLB larger than the e500 > > maximum > > (256 MB) > > which made u-boot hang in board_init_f() when trying to create a new > > stack > > in RAM. > > I have an mpc8540 with one 1GB dimm. > > > > Signed-off-by: Fredrik Arnerup > Applied to HEAD, thanks! Andy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] 85xx: Fix the wrong BCSR address of 8569MDS
On Thu, May 14, 2009 at 9:27 PM, Dave Liu wrote: > The BCSR17[7] = 1 will unlock the write protect of FLASH. > The WP# pin only controls the write protect of top/bottom sector, > That is why we can save env, but we can't write the first sector > before the patch. > > Signed-off-by: Dave Liu Applied to HEAD, thanks! Andy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] 85xx: Fix the wrong SYS_CLK_IN for 8569MDS
On Mon, May 18, 2009 at 4:49 AM, Dave Liu wrote: > The SYS_CLK_IN of MPC8569MDS is 66.66MHz, > The DDR_CLK_IN is same with SYS_CLK_IN in 8569 processor. > so, change the SYS_CLK_IN from 66MHz to 66.66MHz. > > Signed-off-by: Dave Liu Applied to HEAD, thanks! Andy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] TSEC ethernet controller problems (crc errors/corruption)
Did you check the GMII interface (H/W)? Like EC_GTX_CLK125, this signal is input for TSEC block for 1000Mbps case. When you used the 100Mbps, the GTX_CLK125 is not used. Because you are Using the MII interface for 100Mbps case. Thanks, Dave ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/8] Add simple hwconfig infrastructure
On Tue, Jun 02, 2009 at 03:51:29PM -0500, Andy Fleming wrote: > On Wed, Apr 29, 2009 at 4:50 PM, Anton Vorontsov > wrote: > > > This patch implements simple hwconfig infrastructure: an > > interface for software knobs to control a hardware. > > > > This is very simple implementation, i.e. it is implemented > > via `hwconfig' environment variable. Later we could write > > some "hwconfig " commands, ncurses > > interface for Award BIOS-like interface, and frame-buffer > > interface for AMI GUI[1] BIOS-like interface with mouse > > support[2]. > > > ...Any updates on this? It looks like your eSDHC patches rely on it, so I > can't apply any of these 8 patches until this one passes. :) Yeah... I've been on a vacation, and then got some internal MV work to do, but now I'm slowly but surely catching up on the pending community work, so I will post updated patches soon. Thanks, -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] TSEC ethernet controller problems (crc errors/ corruption)
On Tue, Jun 02, 2009 at 02:25:03PM -0700, Ira Snyder wrote: > > > > And what is the SICRH[30-31]? > > Did you have the matching settings for GMII with 3.3V? > > > > => md e118 1 > e118: 0002 > > This looks wrong. The MPC8349EMDS board has the exact same setting in > that register. Writing 0x0 to the SICRH register did not cause the > problem to go away. > The MPC8349EMDS config has had that setting since it was imported into U-Boot. I've copied the relevant part of include/configs/MPC8349EMDS.h below. #define CONFIG_SYS_SICRH SICRH_TSOBI1 This seems wrong for the MPC8349EMDS board. I tried setting the register value to 0x0 by hand on my MPC8349EMDS eval board, and the network still works as expected. Is this a bug in the MPC8349EMDS config? Thanks, Ira ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: Remove return from mmc_init for non SD 2.0 compatible cards.
On Thu, May 7, 2009 at 4:52 PM, Yauhen Kharuzhy wrote: > On Thu, May 07, 2009 at 03:13:40PM -0500, Andy Fleming wrote: > > On Thu, May 7, 2009 at 5:08 AM, Yauhen Kharuzhy > wrote: > > > Cards which are not compatible with SD 2.0 standard, cat return > response > > > for CMD8 command, but it will be invalid in terms of SD 2.0. We should > > > accept this case as admissible. > > > > > > Signed-off-by: Yauhen Kharuzhy > Applied to HEAD, with minor commit message modifications Andy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: Fix decoding of SCR & function switch data on little-endian machines
On Wed, May 6, 2009 at 4:43 PM, Yauhen Kharuzhy wrote: > SCR & switch data are read from card as big-endian words and should be > converted to CPU byte order. > > Signed-off-by: Yauhen Kharuzhy Applied to HEAD, first removing the debug output you left in. Andy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] TSEC ethernet controller problems (crc errors/corruption)
> > => md e118 1 > > e118: 0002 > > > > This looks wrong. The MPC8349EMDS board has the exact same > setting in > > that register. Writing 0x0 to the SICRH register did not cause the > > problem to go away. > > > > The MPC8349EMDS config has had that setting since it was imported into > U-Boot. I've copied the relevant part of include/configs/MPC8349EMDS.h > below. > > #define CONFIG_SYS_SICRH SICRH_TSOBI1 > > This seems wrong for the MPC8349EMDS board. I tried setting > the register > value to 0x0 by hand on my MPC8349EMDS eval board, and the > network still > works as expected. > > Is this a bug in the MPC8349EMDS config? I will roll back the history to have a check it. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: fix SD card SCR register decoding on little endian systems
On Tue, Jun 2, 2009 at 10:47 AM, Herrmann Ulrich < ulrich.herrm...@austriamicrosystems.com> wrote: > > Rabin Vincent's fix for little endian systems fixes only the issues > regarding responses received on the command line. > However the SD card's SCR register is received on the DAT0 line > - therefore it must be handled in an endian independent way. > > This is an addendum to "[PATCH 4/5] mmc: fix response decoding on little > endian" from rabin at rab.in. I ended up applying another patch which solved the same problem, mostly because it was further back in the queue. Changes should show up in my tree soon, and the pull request will follow soon after. Andy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] TSEC ethernet controller problems (crc errors/corruption)
> Did you check the GMII interface (H/W)? > Like EC_GTX_CLK125, this signal is input for TSEC block for > 1000Mbps case. > When you used the 100Mbps, the GTX_CLK125 is not used. Because you are > Using the MII interface for 100Mbps case. IIRC, the MV88E has some h/w config option to configure something such like interface mode, enable/disable 125MHz clock...if you are using the 125MHz of PHY acts as source of GTX_CLK125. you need care it. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] TSEC ethernet controller problems (crc errors/ corruption)
On Tue, 2 Jun 2009 15:19:18 -0700 Ira Snyder wrote: > On Tue, Jun 02, 2009 at 02:25:03PM -0700, Ira Snyder wrote: > > > > > > And what is the SICRH[30-31]? > > > Did you have the matching settings for GMII with 3.3V? > > > > > > > => md e118 1 > > e118: 0002 > > > > This looks wrong. The MPC8349EMDS board has the exact same setting in > > that register. Writing 0x0 to the SICRH register did not cause the > > problem to go away. > > > > The MPC8349EMDS config has had that setting since it was imported into > U-Boot. I've copied the relevant part of include/configs/MPC8349EMDS.h > below. > > #define CONFIG_SYS_SICRH SICRH_TSOBI1 > > This seems wrong for the MPC8349EMDS board. I tried setting the register > value to 0x0 by hand on my MPC8349EMDS eval board, and the network still > works as expected. still works or does not work? 100mbit or 1000mbit?? > Is this a bug in the MPC8349EMDS config? It might be. Another thing that changed wrt that area was commit 846f1574. Assuming this is all still clear to me, perhaps what that patch does should be made 8349-revision dependent? Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/7] arm: add support for CONFIG_GENERIC_MMC
On 10:56 Thu 28 May , Andy Fleming wrote:
>On Fri, May 22, 2009 at 7:27 PM, Jean-Christophe PLAGNIOL-VILLARD
> wrote:
>
> On 03:56 Wed 20 May , Ilya Yanok wrote:
> > Signed-off-by: Ilya Yanok
> > ---
> > lib_arm/board.c |7 +++
> > 1 files changed, 7 insertions(+), 0 deletions(-)
> >
> > diff --git a/lib_arm/board.c b/lib_arm/board.c
> > index 5d05d9b..268532f 100644
> > --- a/lib_arm/board.c
> > +++ b/lib_arm/board.c
> > @@ -48,6 +48,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #ifdef CONFIG_DRIVER_SMC9
> > #include "../drivers/net/smc9.h"
> > @@ -439,6 +440,12 @@ extern void davinci_eth_set_mac_addr (const
> u_int8_t *addr);
> > #ifdef BOARD_LATE_INIT
> > board_late_init ();
> > #endif
> > +
> > +#ifdef CONFIG_GENERIC_MMC
> > + puts ("MMC: ");
> > + mmc_initialize (gd->bd);
> > +#endif
> do you use a embedded mmc?
> otherwise I'll prefer to not init the mmc at the board init but on need
>
>This is the same way ethernet is initialized. mmc_initialize should not
>perform any SD/MMC transactions, but should set up the driver, and
>register with the MMC subsystem. Without doing this, there's no way to
>address the MMC device from the command line...
ok
Best Regards,
J.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM DaVinci: Adding new Header file
> diff --git a/include/asm-arm/arch-davinci/devices.h
> b/include/asm-arm/arch-davinci/devices.h
> new file mode 100644
> index 000..fd7f6d0
> --- /dev/null
> +++ b/include/asm-arm/arch-davinci/devices.h
> @@ -0,0 +1,45 @@
> +/*
> + *
> + * Copyright (C) 2009 Texas Instruments.
> + *
> + * 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 SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
> + * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
> + * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN
> + * NO EVENT SHALL THE AUTHOR BELIABLE FOR ANY DIRECT, INDIRECT,
> + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
> + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
> + * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
> + * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
> + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
> + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> + *
> + * You should have received a copy of the GNU General Public License along
> + * with this program; if not, write to the Free Software Foundation, Inc.,
> + * 675 Mass Ave, Cambridge, MA 02139, USA.
> + *
> + */
> +#ifndef __ASM_ARCH_DEVICES_H
> +#define __ASM_ARCH_DEVICES_H
> +
> +#include
> +
> +#define REG(addr) (*(volatile unsigned int *)(addr))
> +#define REG_P(addr) ((volatile unsigned int *)(addr))
> +
> +typedef volatile unsigned intdv_reg;
> +typedef volatile unsigned int*dv_reg_p;
> +
> +void lpsc_on(unsigned int id);
> +void dsp_on(void);
> +
> +void davinci_enable_uart0(void);
> +void davinci_enable_emac(void);
> +void davinci_enable_i2c(void);
> +void davinci_errata_workarounds(void);
> +
> +#endif /* __ASM_ARCH_DEVICES_H */
> diff --git a/include/asm-arm/arch-davinci/emac_defs.h
> b/include/asm-arm/arch-davinci/emac_defs.h
> index c11161f..4a5e79d 100644
> diff --git a/include/asm-arm/arch-davinci/emif_defs.h
> b/include/asm-arm/arch-davinci/emif_defs.h
> index 646fc77..53e84f6 100644
> --- a/include/asm-arm/arch-davinci/emif_defs.h
> +++ b/include/asm-arm/arch-davinci/emif_defs.h
> @@ -23,6 +23,7 @@
> #define _EMIF_DEFS_H_
>
> #include
> +#include
>
> typedef struct {
> dv_reg ERCSR;
> diff --git a/include/asm-arm/arch-davinci/hardware.h
> b/include/asm-arm/arch-davinci/hardware.h
> index 313b3f3..0a685a7 100644
> --- a/include/asm-arm/arch-davinci/hardware.h
> +++ b/include/asm-arm/arch-davinci/hardware.h
> @@ -36,12 +36,6 @@
> #include
> #include
>
> -#define REG(addr) (*(volatile unsigned int *)(addr))
> -#define REG_P(addr) ((volatile unsigned int *)(addr))
> -
> -typedef volatile unsigned intdv_reg;
> -typedef volatile unsigned int * dv_reg_p;
we need to drop this REG and REG_P stuff and use instead generic accessor
and for this patch move them will not help. The idea behind the devices.h is
to have a header where will have all device init prototypes
Best Regards,
J.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Patch] bss section initialization on s3c44b0
On 13:55 Thu 21 May , Ming-Dien Chang wrote:
> Clear the .BSS section for S3C44B0 to get a zero-filled .BSS section.
>
> Signed-off-by : Ming-Dien Chang
>
>
> diff --git a/cpu/s3c44b0/start.S b/cpu/s3c44b0/start.S
> index f5a3d3a..a6d27aa 100644
> --- a/cpu/s3c44b0/start.S
> +++ b/cpu/s3c44b0/start.S
> @@ -154,6 +154,25 @@ vector_copy_loop:
> ble vector_copy_loop
> #endif /* CONFIG_SKIP_RELOCATE_UBOOT */
>
> + /*
> +* Initialize .bss section.
> +*/
> + mov r2, #0
> + mov r3, #0
> + mov r4, #0
> + mov r5, #0
> + mov r6, #0
> + mov r7, #0
> + mov r8, #0
> + mov r9, #0
> + mov r10, #0
> + ldr r0, _bss_start
> + ldr r1, _bss_end
> +zerolize:
> + stmia r0!, {r2-r10}
> + cmp r0, r1
> + blt zerolize
> +
please use the same code as other arm cpu start.S
as example cpu/arm926ejs/start.S
Best Regards,
J.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH-ARM] Add support for Embest SBC2440-II Board
On 03:24 Sat 23 May , kevin.morf...@fearnside-systems.co.uk wrote: > > Implementation based on the existing u-boot support for S3C2410-based boards. > u-boot programmed into NOR flash. > > Tested on an SBC2440-II Board using tftp to copy the files from a server and > programming them into NAND flash. > > MAKEALL used to build all LIST_ARM9 targets only - no other architectures > built as the changes only affect ARM9-based boards. > > Signed-off-by: Kevin Morfitt please limit your comments to 80 chars per line could you split this patch in multiple subset as adding the 2440 support, addind the nand drivers and then adding the board. This will really simplify the review > --- > MAKEALL|1 + please add MAINTAINERS entry > Makefile |3 + > board/embest/sbc2440ii/Makefile| 55 +++ > board/embest/sbc2440ii/config.mk | 25 +++ > board/embest/sbc2440ii/lowlevel_init.S | 219 +++ > board/embest/sbc2440ii/sbc2440ii.c | 127 > board/embest/sbc2440ii/u-boot.lds | 56 +++ > common/serial.c|4 +- > cpu/arm920t/s3c24x0/speed.c| 83 --- > cpu/arm920t/s3c24x0/timer.c|6 +- > cpu/arm920t/s3c24x0/usb.c |6 +- > cpu/arm920t/s3c24x0/usb_ohci.c |2 + > cpu/arm920t/start.S| 35 - > drivers/i2c/s3c24x0_i2c.c | 18 +++ > drivers/mtd/nand/Makefile |2 +- > drivers/mtd/nand/s3c2410_nand.c| 223 +++- > drivers/rtc/s3c24x0_rtc.c |2 + > drivers/serial/serial_s3c24x0.c|2 + > include/common.h |3 +- > include/configs/sbc2440ii.h| 252 > > include/s3c2440.h | 231 + > include/s3c24x0.h | 83 +++ > 22 files changed, 1362 insertions(+), 76 deletions(-) > create mode 100644 board/embest/sbc2440ii/Makefile > create mode 100644 board/embest/sbc2440ii/config.mk > create mode 100644 board/embest/sbc2440ii/lowlevel_init.S > create mode 100644 board/embest/sbc2440ii/sbc2440ii.c > create mode 100644 board/embest/sbc2440ii/u-boot.lds > create mode 100644 include/configs/sbc2440ii.h > create mode 100644 include/s3c2440.h > > diff --git a/MAKEALL b/MAKEALL > index c98d03a..e7235e4 100755 > + */ > + > +#include > +#include > + > +/* > + * Taken from linux/arch/arm/boot/compressed/head-s3c2410.S > + * > + * Copyright (C) 2002 Samsung Electronics SW.LEE > + */ > + > +#define BWSCON 0x4800 > + > +#define DW8 (0x0) > +#define DW16 (0x1) > +#define DW32 (0x2) > +#define WAIT (0x1 << 2) > +#define UBLB (0x1 << 3) what is all theses macro? for what use? > + > +#define B1_BWSCON(DW16) > +#define B2_BWSCON(DW16) > +#define B3_BWSCON(DW16 + WAIT + UBLB) > +#define B4_BWSCON(DW16) > +#define B5_BWSCON(DW16) > +#define B6_BWSCON(DW32) > +#define B7_BWSCON(DW32) > diff --git a/board/embest/sbc2440ii/sbc2440ii.c > b/board/embest/sbc2440ii/sbc2440ii.c > new file mode 100644 > index 000..e0599dd > --- /dev/null > +++ b/board/embest/sbc2440ii/sbc2440ii.c > @@ -0,0 +1,127 @@ > +/* > + * (C) Copyright 2002 > + * Sysgo Real-Time Solutions, GmbH > + * Marius Groeger > + * > + * (C) Copyright 2002 > + * David Mueller, ELSOFT AG, > + * > + * (C) Copyright 2005 > + * JinHua Luo, GuangDong Linux Center, > + * > + * Modified for the Embest SBC2440-II by > + * (C) Copyright 2009 > + * Kevin Morfitt, Fearnside Systems Ltd, > > + * > + * See file CREDITS for list of people who contributed to this > + * project. > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License as > + * published by the Free Software Foundation; either version 2 of > + * the License, or (at your option) any later version. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + * You should have received a copy of the GNU General Public License > + * along with this program; if not, write to the Free Software > + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, > + * MA 02111-1307 USA > + */ > + > +#include > +#include > + > +DECLARE_GLOBAL_DATA_PTR; > + > +/* Configure the PLLs for MPLL = 400MHz, UPLL = 48MHz > + The clock frequency ratios are set to 1:4:8 ie: > + PCLK = 50MHz > + HCLK = 100MHz > + FCLK = 400MHz > + */ > +/* The MPLL values. */ > +#define M_MDIV 0x5C > +#define M_PDIV 1 > +#define M_SDIV 1 > + >
[U-Boot] [PATCH 1/3] Fix a typo in the instructions on using omap3's gpio interface.
Using the example for reading a gpio, shows the problem.
NULL should be the gpio number.
Signed-off-by: Tom Rix
---
doc/README.omap3 |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/doc/README.omap3 b/doc/README.omap3
index e05e816..66e781d 100644
--- a/doc/README.omap3
+++ b/doc/README.omap3
@@ -106,7 +106,7 @@ To clear a bit :
To read a bit :
if (!omap_request_gpio(N)) {
- omap_set_gpio_direction(NULL, 1);
+ omap_set_gpio_direction(N, 1);
val = omap_get_gpio_datain(N);
omap_free_gpio(N);
}
--
1.6.0.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] Beagle Convert the board version detection to use the OMAP3 GPIO interface.
There is no new functionality in the change.
This change is a conversion from the using raw register access to using
the OMAP3 GPIO API described in doc/README.omap3.
Signed-off-by: Tom Rix
---
board/omap3/beagle/beagle.c | 32 ++--
1 files changed, 18 insertions(+), 14 deletions(-)
diff --git a/board/omap3/beagle/beagle.c b/board/omap3/beagle/beagle.c
index 7eb70ee..d268e18 100644
--- a/board/omap3/beagle/beagle.c
+++ b/board/omap3/beagle/beagle.c
@@ -33,6 +33,7 @@
#include
#include
#include
+#include
#include
#include "beagle.h"
@@ -57,7 +58,7 @@ int board_init(void)
/*
* Routine: beagle_get_revision
- * Description: Return revision of the BeagleBoard this code is running on.
+ * Description: Return the revision of the BeagleBoard this code is running on.
* If it is a revision Ax/Bx board, this function returns 0,
* on a revision C board you will get a 1.
*/
@@ -74,22 +75,25 @@ int beagle_get_revision(void)
*/
void beagle_identify(void)
{
- gpio_t *gpio6_base = (gpio_t *)OMAP34XX_GPIO6_BASE;
-
- /* Configure GPIO 171 as input */
- writel(readl(&gpio6_base->oe) | GPIO11, &gpio6_base->oe);
-
- /* Get value of GPIO 171 */
- beagle_revision_c = readl(&gpio6_base->datain) & BOARD_REVISION_MASK;
+ beagle_revision_c = 0;
+ if (!omap_request_gpio(171)) {
+ unsigned int val;
+
+ omap_set_gpio_direction(171, 1);
+ val = omap_get_gpio_datain(171);
+ omap_free_gpio(171);
+
+ if (val)
+ beagle_revision_c = 0;
+ else
+ beagle_revision_c = 1;
+ }
printf("Board revision ");
- if (beagle_revision_c) {
- printf("Ax/Bx\n");
- beagle_revision_c = 0;
- } else {
+ if (beagle_revision_c)
printf("C\n");
- beagle_revision_c = 1;
- }
+ else
+ printf("Ax/Bx\n");
}
/*
--
1.6.0.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] ZOOM2 detect the version of the zoom2
Jean-Christophe,
Based on your review I have made the changes you asked for.
Tom
> @@ -60,6 +61,46 @@ static u32 gpmc_serial_TL16CP754C[GPMC_MAX_REG] = {
> 0x1D0904C4, 0
> };
>
> +/* Used to track the revision of the board */
> +int zoom2_revision = ZOOM2_REVISION_UNKNOWN;
add static and as the beagle provide a function to get the current version
> +
Tom : Ok added
See
+/* Used to track the revision of the board */
+static ZOOM2_REVISION zoom2_revision = ZOOM2_REVISION_UNKNOWN;
+
+/*
+ * Routine: zoom2_get_revision
+ * Description: Return the revision of the Zoom2 this code is running on.
+ */
+ZOOM2_REVISION zoom2_get_revision(void)
+{
+ return zoom2_revision;
+}
---
> + printf("Board revision ");
> + if (ZOOM2_REVISION_PRODUCTION == zoom2_revision)
> + printf("Production\n");
> + else if (ZOOM2_REVISION_BETA == zoom2_revision)
> + printf("Beta\n");
> + else
> + printf("Unknown\n");
please use switch
> +}
Tom : Ok done.
See
+ switch (zoom2_revision) {
+ case (ZOOM2_REVISION_PRODUCTION):
+ printf("Production\n");
+ break;
+ case (ZOOM2_REVISION_BETA):
+ printf("Beta\n");
+ break;
+ default:
+ printf("Unknown\n");
+ break;
+ }
+}
---
> +#define ZOOM2_REVISION_UNKNOWN 0
> +#define ZOOM2_REVISION_ALPHA 1
> +#define ZOOM2_REVISION_BETA 2
> +#define ZOOM2_REVISION_PRODUCTION3
please use an emum
Tom : Ok
See
+typedef enum {
+ ZOOM2_REVISION_UNKNOWN = 0,
+ ZOOM2_REVISION_ALPHA,
+ ZOOM2_REVISION_BETA,
+ ZOOM2_REVISION_PRODUCTION
+} ZOOM2_REVISION;
--
Also changed this comment in beagle.c
/*
* Routine: beagle_get_revision
- * Description: Return revision of the BeagleBoard this code is running on.
+ * Description: Return the revision of the BeagleBoard this code is running on.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] ZOOM2 detect the version of the zoom2 board at runtime.
There are currently 3 versions of the zoom2 board.
The production board, that is currently being released.
The beta board, similar in form to the production board but not released.
The alpha board, a set of PCBs with a very limited circulation.
GPIO 94 is used to determine the version of the board. If GPIO 94 is clear,
the board is a production board, otherwise it is a beta board.
The alpha board will likely be mistaken for a beta board. An alpha board
was unavailible for testing.
This has been tested on the beta and production boards.
Signed-off-by: Tom Rix
---
board/omap3/zoom2/zoom2.c | 62 ++--
board/omap3/zoom2/zoom2.h |9 ++
2 files changed, 68 insertions(+), 3 deletions(-)
diff --git a/board/omap3/zoom2/zoom2.c b/board/omap3/zoom2/zoom2.c
index e5c248d..94231da 100644
--- a/board/omap3/zoom2/zoom2.c
+++ b/board/omap3/zoom2/zoom2.c
@@ -33,6 +33,7 @@
#include
#endif
#include
+#include
#include
#include
#include
@@ -60,6 +61,60 @@ static u32 gpmc_serial_TL16CP754C[GPMC_MAX_REG] = {
0x1D0904C4, 0
};
+/* Used to track the revision of the board */
+static ZOOM2_REVISION zoom2_revision = ZOOM2_REVISION_UNKNOWN;
+
+/*
+ * Routine: zoom2_get_revision
+ * Description: Return the revision of the Zoom2 this code is running on.
+ */
+ZOOM2_REVISION zoom2_get_revision(void)
+{
+ return zoom2_revision;
+}
+
+/*
+ * Routine: zoom2_identify
+ * Description: Detect which version of Zoom2 we are running on.
+ */
+void zoom2_identify(void)
+{
+ /*
+* To check for production board vs beta board,
+* check if gpio 94 is clear.
+*
+* No way yet to check for alpha board identity.
+* Alpha boards were produced in very limited quantities
+* and they are not commonly used. They are mentioned here
+* only for completeness.
+*/
+ if (!omap_request_gpio(94)) {
+ unsigned int val;
+
+ omap_set_gpio_direction(94, 1);
+ val = omap_get_gpio_datain(94);
+ omap_free_gpio(94);
+
+ if (val)
+ zoom2_revision = ZOOM2_REVISION_BETA;
+ else
+ zoom2_revision = ZOOM2_REVISION_PRODUCTION;
+ }
+
+ printf("Board revision ");
+ switch (zoom2_revision) {
+ case (ZOOM2_REVISION_PRODUCTION):
+ printf("Production\n");
+ break;
+ case (ZOOM2_REVISION_BETA):
+ printf("Beta\n");
+ break;
+ default:
+ printf("Unknown\n");
+ break;
+ }
+}
+
/*
* Routine: board_init
* Description: Early hardware init.
@@ -96,10 +151,11 @@ int board_init (void)
* Routine: misc_init_r
* Description: Configure zoom board specific configurations
*/
-int misc_init_r (void)
+int misc_init_r(void)
{
- power_init_r ();
- dieid_num_r ();
+ zoom2_identify();
+ power_init_r();
+ dieid_num_r();
return 0;
}
diff --git a/board/omap3/zoom2/zoom2.h b/board/omap3/zoom2/zoom2.h
index cae8a7a..b12b0fa 100644
--- a/board/omap3/zoom2/zoom2.h
+++ b/board/omap3/zoom2/zoom2.h
@@ -32,6 +32,15 @@ const omap3_sysinfo sysinfo = {
"NAND",
};
+typedef enum {
+ ZOOM2_REVISION_UNKNOWN = 0,
+ ZOOM2_REVISION_ALPHA,
+ ZOOM2_REVISION_BETA,
+ ZOOM2_REVISION_PRODUCTION
+} ZOOM2_REVISION;
+
+extern ZOOM2_REVISION zoom2_get_revision(void);
+
/*
* IEN - Input Enable
* IDIS- Input Disable
--
1.6.0.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] update nand.h to support address more than 0x80000000
2009/6/3 Scott Wood
>
> On Tue, Jun 02, 2009 at 07:27:01PM +0800, adrian wen wrote:
> > Hi all,
> >
> > I found a bug in nand.h which prevent UBOOT to supprt large NAND chip.
> >
> > The bug description as below:
> > In the original implementation, we use a wrapper function in
> > nand.h to facilitate nand_base function usage in other files,
> > like cmd_nand.c, nand_util.c etc.
> >
> > However, the wrapper in nand.h is using off_t which is long type.
> > If we pass a address like 0x8000, which is allowed by nand_base.c,
> > the wrapper would recognize it as a negative num. So we would get a
> > huge num when this parameter get into nand_base.c
> >
> > Fix it by replacing off_t to loff_t type.
> >
> > Signed-off-by: Lei Wen
>
> A substantially similar patch was posted here:
> http://lists.denx.de/pipermail/u-boot/2009-May/052847.html
>
> I'm fine with this change, but it should also handle large erases.
>
> -Scott
I don't quitly catch the meaning. Do you mean that uboot erases begin
with large address or large length?
This patch only solve the wrapper bug.
For the nand_block_isbad as a example, this function defined in nand.h as:
static inline int nand_block_isbad(nand_info_t *info, off_t ofs)
{
return info->block_isbad(info, ofs);
}
However, in nand_base.c, we define this function as:
static int nand_block_markbad(struct mtd_info *mtd, loff_t ofs)
Also, in nand_util.c, it use a lot of nand_block_markbad, which is the
one _defined_ in nand.h. So the problem comes that when we pass a
address greater than 0x8000, the off_t type would recognize it as
a negative number, while loff_t recognize it valid.
When this _0x8000_ pass to the nand_block_markbad in nand_base.c,
it would be recognized as 0x8000, which is caused by the
wrapper in nand.h.
-Adrian
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] ZOOM2 detect the version of the zoom2 board at runtime.
Jean-Christophe,
I have resubmitted the board revision patches based on your comments.
Tom
Jean-Christophe PLAGNIOL-VILLARD wrote:
+/* Used to track the revision of the board */
+int zoom2_revision = ZOOM2_REVISION_UNKNOWN;
add static and as the beagle provide a function to get the current version
Ok see
+/* Used to track the revision of the board */
+static ZOOM2_REVISION zoom2_revision = ZOOM2_REVISION_UNKNOWN;
+
+/*
+ * Routine: zoom2_get_revision
+ * Description: Return the revision of the Zoom2 this code is running on.
+ */
+ZOOM2_REVISION zoom2_get_revision(void)
+{
+ return zoom2_revision;
+}
+ printf("Board revision ");
+ if (ZOOM2_REVISION_PRODUCTION == zoom2_revision)
+ printf("Production\n");
+ else if (ZOOM2_REVISION_BETA == zoom2_revision)
+ printf("Beta\n");
+ else
+ printf("Unknown\n");
please use switch
Ok see
+ printf("Board revision ");
+ switch (zoom2_revision) {
+ case (ZOOM2_REVISION_PRODUCTION):
+ printf("Production\n");
+ break;
+ case (ZOOM2_REVISION_BETA):
+ printf("Beta\n");
+ break;
+ default:
+ printf("Unknown\n");
+ break;
+ }
+}
+#define ZOOM2_REVISION_UNKNOWN 0
+#define ZOOM2_REVISION_ALPHA 1
+#define ZOOM2_REVISION_BETA2
+#define ZOOM2_REVISION_PRODUCTION 3
please use an emum
Ok see
+typedef enum {
+ ZOOM2_REVISION_UNKNOWN = 0,
+ ZOOM2_REVISION_ALPHA,
+ ZOOM2_REVISION_BETA,
+ ZOOM2_REVISION_PRODUCTION
+}
I also made a slight change to the beagle.c in patch 3/3 comment here
/*
* Routine: beagle_get_revision
- * Description: Return revision of the BeagleBoard this code is running on.
+ * Description: Return the revision of the BeagleBoard this code is
running on.
* If it is a revision Ax/Bx board, this function returns 0,
* on a revision C board you will get a 1.
*/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] pci bus scan in u-boot-1.0.2
Tks, maybe update to recent code is the best way! 在2009-06-02，"Wolfgang Denk" 写道： Dear xiaoguizi007, In message <20207172.786581243919864464.javamail.corem...@bj163app34.163.com> you wrote: > > I'm tring using pci function of u-boot-1.0.2. But while the programm > run into function pci_hose_scan_bus() in /drivers/pci.c, it looks like go to > dead and will never run. So, I assert some debug infomation, and then get the > problem,maybe it is p > ci_hose_##rw##_config_##size() function. Because this function will never > return this time! > Can anybody help me! U-Boot 1.0.2 is extremely old. Please consider it unsupported and update to recent 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 The perversity of nature is nowhere better demonstrated by the fact that, when exposed to the same atmosphere, bread becomes hard while crackers become soft. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
