[U-Boot] SMDK2410 board
I'm trying to get u-boot running on a smdk2410-based board. I'm using openocd and jtag and am trying to load u-boot into ram as follows: load_image u-boot.bin 0x33f8 Which *seems* to work: 103668 bytes written at address 0x33f8 downloaded 103668 byte in 0.500045s I then try to run it by using resume 0x33f8 but it doesn't seem that u-boot is executing. What am I doing wrong? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add I2C multibus support for OMAP2/3 boards
Tom Rix wrote:
From: Syed Mohammed Khasim
This was cherry-picked from
repo: http://www.beagleboard.org/u-boot-arm.git
commit: 52eddcd07c2e7ad61d15bab2cf2d0d21466eaca2
In addition to adding multibus support, this patch
also cleans up the register access. The register
access has been changed from #defines to a structure.
Have you looked at my proposal I sent some hours before your patch?
http://lists.denx.de/pipermail/u-boot/2009-October/063556.html
Signed-off-by: Syed Mohammed Khasim
Signed-off-by: Jason Kridner
Signed-off-by: Tom Rix
---
drivers/i2c/omap24xx_i2c.c | 220 ++-
include/asm-arm/arch-omap24xx/i2c.h | 52 ++---
include/asm-arm/arch-omap3/i2c.h| 48 +---
include/configs/omap3_beagle.h |1 +
4 files changed, 209 insertions(+), 112 deletions(-)
diff --git a/drivers/i2c/omap24xx_i2c.c b/drivers/i2c/omap24xx_i2c.c
index 1a4c8c9..763d2f8 100644
--- a/drivers/i2c/omap24xx_i2c.c
+++ b/drivers/i2c/omap24xx_i2c.c
@@ -1,7 +1,7 @@
/*
* Basic I2C functions
*
- * Copyright (c) 2004 Texas Instruments
+ * Copyright (c) 2004, 2009 Texas Instruments
*
* This package is free software; you can redistribute it and/or
* modify it under the terms of the license found in the file
@@ -25,10 +25,18 @@
#include
#include
+#ifdef CONFIG_OMAP34XX
+#define I2C_NUM_IF 3
+#else
+#define I2C_NUM_IF 2
+#endif
I prefer something like I2C_BUS_MAX for this. And move it to header
file. Moving it OMAP2 and OMAP3 i2c.h headers will remove the #ifdef, too.
static void wait_for_bb (void);
static u16 wait_for_pin (void);
static void flush_fifo(void);
+static i2c_t *i2c = (i2c_t *)I2C_DEFAULT_BASE;
Looking at the other OMAP3 files, the recent syntax seems to be
static struct i2c *i2c_base = (struct i2c *)I2C_DEFAULT_BASE;
Just to be consistent.
void i2c_init (int speed, int slaveadd)
{
int psc, fsscll, fssclh;
@@ -95,30 +103,30 @@ void i2c_init (int speed, int slaveadd)
sclh = (unsigned int)fssclh;
}
- writew(0x2, I2C_SYSC); /* for ES2 after soft reset */
+ writew(0x2, &i2c->sysc); /* for ES2 after soft reset */
udelay(1000);
- writew(0x0, I2C_SYSC); /* will probably self clear but */
+ writew(0x0, &i2c->sysc); /* will probably self clear but */
- if (readw (I2C_CON) & I2C_CON_EN) {
- writew (0, I2C_CON);
- udelay (5);
+ if (readw(&i2c->con) & I2C_CON_EN) {
+ writew(0, &i2c->con);
+ udelay(5);
udelay: Are this formatting changes? You are correct, a lot of
formatting improvements are needed here. But they should go to an
other patch.
- writew(psc, I2C_PSC);
- writew(scll, I2C_SCLL);
- writew(sclh, I2C_SCLH);
+ writew(psc, &i2c->psc);
+ writew(scll, &i2c->scll);
+ writew(sclh, &i2c->sclh);
/* own address */
- writew (slaveadd, I2C_OA);
- writew (I2C_CON_EN, I2C_CON);
+ writew(slaveadd, &i2c->oa);
+ writew(I2C_CON_EN, &i2c->con);
/* have to enable intrrupts or OMAP i2c module doesn't work */
- writew (I2C_IE_XRDY_IE | I2C_IE_RRDY_IE | I2C_IE_ARDY_IE |
- I2C_IE_NACK_IE | I2C_IE_AL_IE, I2C_IE);
- udelay (1000);
+ writew(I2C_IE_XRDY_IE | I2C_IE_RRDY_IE | I2C_IE_ARDY_IE |
+ I2C_IE_NACK_IE | I2C_IE_AL_IE, &i2c->ie);
+ udelay(1000);
Formatting change?
flush_fifo();
- writew (0x, I2C_STAT);
- writew (0, I2C_CNT);
+ writew(0x, &i2c->stat);
+ writew(0, &i2c->cnt);
}
static int i2c_read_byte (u8 devaddr, u8 regoffset, u8 * value)
@@ -130,19 +138,19 @@ static int i2c_read_byte (u8 devaddr, u8 regoffset, u8 *
value)
wait_for_bb ();
/* one byte only */
- writew (1, I2C_CNT);
+ writew(1, &i2c->cnt);
/* set slave address */
- writew (devaddr, I2C_SA);
+ writew(devaddr, &i2c->sa);
/* no stop bit needed here */
- writew (I2C_CON_EN | I2C_CON_MST | I2C_CON_STT | I2C_CON_TRX, I2C_CON);
+ writew(I2C_CON_EN | I2C_CON_MST | I2C_CON_STT | I2C_CON_TRX, &i2c->con);
status = wait_for_pin ();
if (status & I2C_STAT_XRDY) {
/* Important: have to use byte access */
- writeb (regoffset, I2C_DATA);
- udelay (2);
- if (readw (I2C_STAT) & I2C_STAT_NACK) {
+ writeb(regoffset, &i2c->data);
+ udelay(2);
Formatting change?
+ if (readw(&i2c->stat) & I2C_STAT_NACK) {
i2c_error = 1;
}
} else {
@@ -151,28 +159,28 @@ static int i2c_read_byte (u8 devaddr, u8 regoffset, u8 *
value)
if (!i2c_error) {
/* free bus, otherwise we can't use a combined transction */
- writew (0, I2C_CON);
- while (readw (I2C_STAT) || (readw (I2C_CON) & I2C_CON_MST)) {
+ write
Re: [U-Boot] SMDK2410 board
Dear David Kaplan, In message <62564a490911010039xb4c7768mb51016cdd42c8...@mail.gmail.com> you wrote: > > I'm using openocd and jtag and am trying to load u-boot into ram as follows: ... > I then try to run it by using resume 0x33f8 but it doesn't seem that > u-boot is executing. > What am I doing wrong? Maybe you failed tor ead the FAQ: http://www.denx.de/wiki/view/DULG/CanUBootBeConfiguredSuchThatItCanBeStartedInRAM 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 That said, there may be good reasons for what you did beyond obsequi- ous sycophantic parody. Perhaps you might be so kind as to elucidate. -- Tom Christiansen in <5ldjbm$jt...@csnews.cs.colorado.edu> ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC 0/5] CAN framework for U-Boot
From: Wolfgang Grandegger This patch series adds a simple CAN framework for U-Boot. The main purpose is to do simple RX/TX testing when the device boots up but the interface functions could also be used for more complex tasks. This is just a RFC and a few more features need to be added or issues to be fixed, like using a generic device interface, if it already exists, and board specific device configuration, e.g. via i82527_register(addr, cfg-params). The sources are based on GPL v2+ code to be compatible with future U-Boot licence requirement. Please comment. Wolfgang Wolfgang Grandegger (5): CAN interface library CAN device test command CAN device driver for the SJA1000 CAN device driver for the Intel 82527 CAN interface support for the TQM855L module Makefile |1 + board/tqc/tqm8xx/tqm8xx.c | 17 ++ common/Makefile |1 + common/cmd_can.c | 119 +++ drivers/can/Makefile | 49 ++ drivers/can/can.c | 88 +++ drivers/can/i82527.c | 366 + drivers/can/sja1000.c | 223 +++ include/can.h | 70 + include/configs/TQM855L.h |8 +- include/i82527.h | 201 + include/sja1000.h | 159 12 files changed, 1301 insertions(+), 1 deletions(-) create mode 100644 common/cmd_can.c create mode 100644 drivers/can/Makefile create mode 100644 drivers/can/can.c create mode 100644 drivers/can/i82527.c create mode 100644 drivers/can/sja1000.c create mode 100644 include/can.h create mode 100644 include/i82527.h create mode 100644 include/sja1000.h ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC 1/5] CAN interface library
From: Wolfgang Grandegger
Signed-off-by: Wolfgang Grandegger
---
Makefile |1 +
drivers/can/Makefile | 47 ++
drivers/can/can.c| 88 ++
include/can.h| 70 +++
4 files changed, 206 insertions(+), 0 deletions(-)
create mode 100644 drivers/can/Makefile
create mode 100644 drivers/can/can.c
create mode 100644 include/can.h
diff --git a/Makefile b/Makefile
index bcb3fe9..dca15e0 100644
--- a/Makefile
+++ b/Makefile
@@ -203,6 +203,7 @@ LIBS += net/libnet.a
LIBS += disk/libdisk.a
LIBS += drivers/bios_emulator/libatibiosemu.a
LIBS += drivers/block/libblock.a
+LIBS += drivers/can/libcan.a
LIBS += drivers/dma/libdma.a
LIBS += drivers/fpga/libfpga.a
LIBS += drivers/gpio/libgpio.a
diff --git a/drivers/can/Makefile b/drivers/can/Makefile
new file mode 100644
index 000..74d2ff5
--- /dev/null
+++ b/drivers/can/Makefile
@@ -0,0 +1,47 @@
+#
+# Copyright 2000-2008
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB:= $(obj)libcan.a
+
+COBJS-$(CONFIG_CAN)+= can.o
+
+COBJS := $(COBJS-y)
+SRCS := $(COBJS:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS))
+
+all: $(LIB)
+
+$(LIB):$(obj).depend $(OBJS)
+ $(AR) $(ARFLAGS) $@ $(OBJS)
+
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+
diff --git a/drivers/can/can.c b/drivers/can/can.c
new file mode 100644
index 000..c09bccf
--- /dev/null
+++ b/drivers/can/can.c
@@ -0,0 +1,88 @@
+/*
+ * (C) Copyright 2007-2009, Wolfgang Grandegger
+ *
+ * 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
+ */
+
+/*
+ * CAN device interface library
+ */
+#include
+#include
+#include
+
+static struct can_dev *can_devs;
+
+static char *baudrates[] = { "125K", "250K", "500K" };
+
+int can_register (struct can_dev* can_dev)
+{
+ struct can_dev* dev;
+
+ can_dev->next = NULL;
+ if (!can_devs)
+ can_devs = can_dev;
+ else {
+ for (dev = can_devs; dev->next; dev = dev->next)
+ ;
+ dev->next = can_dev;
+ }
+
+ printf ("CAN: %s at %lx registered\n", can_dev->name, can_dev->base);
+
+ return 0;
+}
+
+struct can_dev *can_init (int dev_num, int ibaud)
+{
+ struct can_dev *dev;
+ int i;
+
+ if (!can_devs) {
+ puts ("No CAN devices registered\n");
+ return NULL;
+ }
+
+ /* Advance to selected device */
+ for (i = 0, dev = can_devs; dev; i++, dev = dev->next) {
+ if (i == dev_num)
+ break;
+ }
+
+ if (!dev) {
+ printf ("CAN device %d does not exist\n", dev_num);
+ return NULL;
+ }
+
+ printf ("Initializing CAN%d at 0x%08x with baudrate %s\n",
+ i, dev->base, baudrates[ibaud]);
+
+ dev->init (dev, ibaud);
+
+ return dev;
+}
+
+void can_list (void)
+{
+ struct can_dev *dev;
+ int i;
+
+ for (i = 0, dev = can_devs; dev; i++, dev = dev->next)
+ printf ("CAN%d: %s at 0x%p\n", i, dev->name, dev->base);
+}
diff --git a/include/can.h b/include/can.h
new file mode 1006
[U-Boot] [RFC 2/5] CAN device test command
From: Wolfgang Grandegger
Signed-off-by: Wolfgang Grandegger
---
common/Makefile |1 +
common/cmd_can.c | 119 ++
2 files changed, 120 insertions(+), 0 deletions(-)
create mode 100644 common/cmd_can.c
diff --git a/common/Makefile b/common/Makefile
index 3781738..b7f4c22 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -72,6 +72,7 @@ COBJS-$(CONFIG_CMD_BEDBUG) += bedbug.o cmd_bedbug.o
COBJS-$(CONFIG_CMD_BMP) += cmd_bmp.o
COBJS-$(CONFIG_CMD_BOOTLDR) += cmd_bootldr.o
COBJS-$(CONFIG_CMD_CACHE) += cmd_cache.o
+COBJS-$(CONFIG_CMD_CAN) += cmd_can.o
COBJS-$(CONFIG_CMD_CONSOLE) += cmd_console.o
COBJS-$(CONFIG_CMD_CPLBINFO) += cmd_cplbinfo.o
COBJS-$(CONFIG_DATAFLASH_MMC_SELECT) += cmd_dataflash_mmc_mux.o
diff --git a/common/cmd_can.c b/common/cmd_can.c
new file mode 100644
index 000..af7bf34
--- /dev/null
+++ b/common/cmd_can.c
@@ -0,0 +1,119 @@
+/*
+ * (C) Copyright 2007-2009, Wolfgang Grandegger
+ *
+ * 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
+ */
+
+/*
+ * CAN device test command
+ */
+#include
+#include
+#include
+
+static struct can_dev *can_dev;
+
+int do_can (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
+{
+ struct can_msg msg;
+ char op;
+ int i;
+
+ op = argv[1][0];
+
+ if (argc < 2) {
+ can_list ();
+ return 0;
+ }
+
+ if (!can_dev && op != 'i') {
+ can_dev = can_init (0, 0);
+ if (!can_dev)
+ return 1;
+ }
+
+ if (op == 's') {
+ unsigned int level = 0;
+ if (argc > 2)
+ level = simple_strtoul (argv[2], NULL, 10);
+ can_status (can_dev, level);
+ }
+
+ else if (op == 'i') {
+ unsigned int dev_num = 0, ibaud = 0;
+ struct can_dev *dev;
+
+ if (argc > 2)
+ dev_num = simple_strtoul (argv[2], NULL, 10);
+ if (argc > 3) {
+ ibaud = simple_strtoul (argv[3], NULL, 10);
+ if (ibaud > 2)
+ ibaud = 2;
+ }
+ dev = can_init (dev_num, ibaud);
+ if (!dev)
+ return 1;
+ can_dev = dev;
+ }
+
+ else if (op == 'r') {
+ while (!can_recv (can_dev, &msg)) {
+ printf ("<0x%03x>", msg.id & CAN_SFF_MASK);
+
+ printf (" [%d]", msg.dlc);
+ if (msg.id & CAN_RTR_FLAG)
+ puts (" rtr");
+ else {
+ for (i = 0; i < msg.dlc; i++)
+ printf (" %02x", msg.data[i]);
+ }
+ puts ("\n");
+ }
+ } else if (op == 'x') {
+ memset (&msg, 0, sizeof (msg));
+ msg.id = 0x123;
+ if (argc > 2)
+ msg.id = simple_strtoul (argv[2], NULL, 16);
+ for (i = 0; argc > (3 + i); i++, msg.dlc++) {
+ msg.data[i] = simple_strtoul (argv[3 + i], NULL, 16);
+ }
+ if (argc == 2)
+ printf ("Transmitting id %#x dlc %d\n",
+ msg.id, msg.dlc);
+
+ if (can_xmit (can_dev, &msg))
+ puts("FAILED\n");
+ else
+ puts("OK\n");
+ } else {
+ printf ("Usage:\n%s\n", cmdtp->usage);
+ return 1;
+ }
+
+ return 0;
+}
+
+U_BOOT_CMD(
+ can, 3, 1, do_can,
+ "can - CAN bus commands\n",
+ "can status [level]\n"
+ "can init [dev] [baud-index]\n"
+ "can xmit [id] [d0] [d1] ... [d7]\n"
+ "can recv, abort with CTRL-C\n"
+);
--
1.6.2.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC 3/5] CAN device driver for the SJA1000
From: Wolfgang Grandegger
Signed-off-by: Wolfgang Grandegger
---
drivers/can/Makefile |3 +-
drivers/can/sja1000.c | 223 +
include/sja1000.h | 159 +++
3 files changed, 384 insertions(+), 1 deletions(-)
create mode 100644 drivers/can/sja1000.c
create mode 100644 include/sja1000.h
diff --git a/drivers/can/Makefile b/drivers/can/Makefile
index 74d2ff5..e2b6bd6 100644
--- a/drivers/can/Makefile
+++ b/drivers/can/Makefile
@@ -25,7 +25,8 @@ include $(TOPDIR)/config.mk
LIB:= $(obj)libcan.a
-COBJS-$(CONFIG_CAN)+= can.o
+COBJS-$(CONFIG_CAN)+= can.o
+COBJS-$(CONFIG_CAN_SJA1000)+= sja1000.o
COBJS := $(COBJS-y)
SRCS := $(COBJS:.o=.c)
diff --git a/drivers/can/sja1000.c b/drivers/can/sja1000.c
new file mode 100644
index 000..b75f01c
--- /dev/null
+++ b/drivers/can/sja1000.c
@@ -0,0 +1,223 @@
+/*
+ * (C) Copyright 2007-2009, Wolfgang Grandegger
+ *
+ * Derived from Xenomai's RT-Socket-CAN driver for SJA1000:
+ *
+ * Copyright (C) 2005,2006 Sebastian Smolorz
+ *
+ *
+ * Copyright (C) 2005, Sascha Hauer, Pengutronix
+ *
+ * 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
+
+#define SJA1000_OCR(SJA_OCR_MODE_NORMAL | SJA_OCR_TX0_PUSHPULL)
+#define SJA1000_CDRSJA_CDR_CAN_MODE
+
+/*
+ * Basic functions to access registers
+ */
+#define sja1000_read_reg(dev, reg) \
+ in_8 ((volatile u8 *)((dev)->base + (reg)))
+
+#define sja1000_write_reg(dev, reg, value) \
+ out_8 ((volatile u8 *)((dev)->base + (reg)), value)
+
+/*
+ * Baudrate table
+ */
+
+static u16 sja1000_btr0btr1[] = {
+ 0x031c, /* 125K */
+ 0x011c, /* 250K */
+ 0x001c, /* 500K */
+};
+
+int sja1000_init (struct can_dev *dev, unsigned int ibaud)
+{
+ int i, wait = 1000;
+ u16 btr0btr1;
+
+ /* Disable the controller's interrupts */
+ sja1000_write_reg (dev, SJA_IER, 0x00);
+
+ /* Set reset mode bit */
+ sja1000_write_reg (dev, SJA_MOD, SJA_MOD_RM);
+
+ /* Read reset mode bit, multiple tests */
+ do {
+ udelay (100);
+ if (sja1000_read_reg (dev, SJA_MOD) & SJA_MOD_RM)
+ break;
+ } while (--wait);
+
+ sja1000_write_reg (dev, SJA_CDR, SJA1000_CDR);
+ sja1000_write_reg (dev, SJA_OCR, SJA1000_OCR);
+
+ sja1000_write_reg (dev, SJA_AMR0, 0xFF);
+ sja1000_write_reg (dev, SJA_AMR1, 0xFF);
+ sja1000_write_reg (dev, SJA_AMR2, 0xFF);
+ sja1000_write_reg (dev, SJA_AMR3, 0xFF);
+
+ sja1000_write_reg (dev, SJA_RXERR, 0);
+ sja1000_write_reg (dev, SJA_TXERR, 0);
+
+ i = sizeof (sja1000_btr0btr1) / sizeof (u16);
+ if (ibaud >= i)
+ ibaud = i - 1;
+ btr0btr1 = sja1000_btr0btr1[ibaud];
+ sja1000_write_reg (dev, SJA_BTR0, (btr0btr1 >> 8) & 0xff);
+ sja1000_write_reg (dev, SJA_BTR1, (btr0btr1 & 0xff));
+
+ /* Clear error code capture (i.e. read it) */
+ sja1000_read_reg (dev, SJA_ECC);
+
+ /* Clear reset mode bit in SJA1000 */
+ sja1000_write_reg (dev, SJA_MOD, 0);
+
+ return 0;
+}
+
+int sja1000_xmit (struct can_dev *dev, struct can_msg *msg)
+{
+ int i;
+ u8 fir;
+
+ if (msg->dlc > 8)
+ msg->dlc = 8;
+ fir = msg->dlc;
+
+ sja1000_write_reg (dev, SJA_ID1, msg->id >> 3);
+ sja1000_write_reg (dev, SJA_ID2, msg->id << 5);
+ for (i = 0; i < msg->dlc; i++)
+ sja1000_write_reg (dev, SJA_DATA_SFF (i), msg->data[i]);
+
+ /* Write frame information register */
+ sja1000_write_reg (dev, SJA_FIR, fir);
+
+ /* Push the 'send' button */
+ sja1000_write_reg (dev, SJA_CMR, SJA_CMR_TR);
+
+ /* Wait some time */
+ for (i = 0; i < CAN_XMIT_TIMEOUT_US; i += 1) {
+ if (sja1000_read_reg (dev, SJA_SR) & SJA_SR_TCS)
+ return 0;
+ if (ctrlc ())
+ break;
+ udelay (1);
+ }
+
+ return -1;
+}
+
+int sja1000_re
[U-Boot] [RFC 4/5] CAN device driver for the Intel 82527
From: Wolfgang Grandegger
Signed-off-by: Wolfgang Grandegger
---
drivers/can/Makefile |1 +
drivers/can/i82527.c | 366 ++
include/i82527.h | 201 +++
3 files changed, 568 insertions(+), 0 deletions(-)
create mode 100644 drivers/can/i82527.c
create mode 100644 include/i82527.h
diff --git a/drivers/can/Makefile b/drivers/can/Makefile
index e2b6bd6..d550a45 100644
--- a/drivers/can/Makefile
+++ b/drivers/can/Makefile
@@ -26,6 +26,7 @@ include $(TOPDIR)/config.mk
LIB:= $(obj)libcan.a
COBJS-$(CONFIG_CAN)+= can.o
+COBJS-$(CONFIG_CAN_I82527) += i82527.o
COBJS-$(CONFIG_CAN_SJA1000)+= sja1000.o
COBJS := $(COBJS-y)
diff --git a/drivers/can/i82527.c b/drivers/can/i82527.c
new file mode 100644
index 000..b3eacd6
--- /dev/null
+++ b/drivers/can/i82527.c
@@ -0,0 +1,366 @@
+/*
+ * (C) Copyright 2007-2009, Wolfgang Grandegger
+ *
+ * Derived from OCAN driver:
+ *
+ * Copyright (C) 2002 Alessandro Rubini
+ * Copyright (C) 2002 System SpA
+ *
+ * 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
+
+#define I82527_TX_OBJ 1
+#define I82527_RX_OBJ 15
+
+/*
+ * Basic functions to access registers
+ */
+#define i82527_read_reg(dev, reg) \
+ in_8 ((volatile u8 *)((dev)->base + (reg)))
+
+#define i82527_write_reg(dev, reg, value) \
+ out_8 ((volatile u8 *)((dev)->base + (reg)), value)
+
+/*
+ * Higher level functions
+ */
+static inline int i82527_read_msgcfg (struct can_dev *dev, int iobj)
+{
+ return i82527_read_reg (dev, (iobj * I82527_MSG_OFF) + I82527_MSG_CFG);
+}
+
+static inline void i82527_write_msgcfg (struct can_dev *dev, int iobj, int val)
+{
+ i82527_write_reg (dev, (iobj * I82527_MSG_OFF) + I82527_MSG_CFG, val);
+}
+
+static inline void i82527_write_std_mask (struct can_dev *dev, u16 val)
+{
+ /* errors are ignored, hmm... */
+ i82527_write_reg (dev, I82527_GMASK_STD, val >> 8);
+ i82527_write_reg (dev, I82527_GMASK_STD + 1, val & 0xff);
+}
+
+static inline void i82527_write_x_mask (struct can_dev *dev, u32 val)
+{
+ /* errors are ignored, hmm... */
+ i82527_write_reg (dev, I82527_GMASK_XTD, val >> 24);
+ i82527_write_reg (dev, I82527_GMASK_XTD + 1, (val >> 16) & 0xff);
+ i82527_write_reg (dev, I82527_GMASK_XTD + 2, (val >> 8) & 0xff);
+ i82527_write_reg (dev, I82527_GMASK_XTD + 3, (val >> 0) & 0xff);
+}
+
+static inline void i82527_write_15_mask (struct can_dev *dev, u32 val)
+{
+ /* errors are ignored, hmm... */
+ i82527_write_reg (dev, I82527_MSG15_MASK, val >> 24);
+ i82527_write_reg (dev, I82527_MSG15_MASK + 1, (val >> 16) & 0xff);
+ i82527_write_reg (dev, I82527_MSG15_MASK + 2, (val >> 8) & 0xff);
+ i82527_write_reg (dev, I82527_MSG15_MASK + 3, (val >> 0) & 0xff);
+}
+
+static inline void i82527_write_msgctrl (struct can_dev *dev, int iobj, u16
val)
+{
+ /* FIXME: this is used little-endian, but doesn't need to be 16b */
+
+ /* errors are ignored, hmm... */
+ i82527_write_reg (dev, (iobj * I82527_MSG_OFF) +
+ I82527_MSG_CTRL, val & 0xff);
+ i82527_write_reg (dev, (iobj * I82527_MSG_OFF) +
+ I82527_MSG_CTRL + 1, val >> 8);
+}
+
+/* write a single byte of msgctrl, twice as fast as the function above */
+static inline void i82527_msgflag (struct can_dev *dev, int iobj, u16 act)
+{
+ if ((act & 0xff) == 0xff)
+ i82527_write_reg (dev, (iobj * I82527_MSG_OFF) +
+ I82527_MSG_CTRL + 1, act >> 8);
+ else
+ i82527_write_reg (dev, (iobj * I82527_MSG_OFF) +
+ I82527_MSG_CTRL, act & 0xff);
+}
+
+static inline u32 i82527_read_msgarb (struct can_dev *dev, int iobj)
+{
+ int port = (iobj * I82527_MSG_OFF) + I82527_MSG_ARBIT;
+
+ u32 ret = (i82527_read_reg (dev, port) << 24 |
+ i82527_read_reg (dev, port + 1) << 16 |
+ i82527_read_reg (dev, port + 2) << 8 |
+ i82527_read_reg (dev, port + 3));
+ return ret;
+}
+
+static inlin
[U-Boot] [RFC 5/5] CAN interface support for the TQM855L module
From: Wolfgang Grandegger
Signed-off-by: Wolfgang Grandegger
---
board/tqc/tqm8xx/tqm8xx.c | 17 +
include/configs/TQM855L.h |8 +++-
2 files changed, 24 insertions(+), 1 deletions(-)
diff --git a/board/tqc/tqm8xx/tqm8xx.c b/board/tqc/tqm8xx/tqm8xx.c
index f92c598..f1aab43 100644
--- a/board/tqc/tqm8xx/tqm8xx.c
+++ b/board/tqc/tqm8xx/tqm8xx.c
@@ -26,6 +26,10 @@
#ifdef CONFIG_PS2MULT
#include
#endif
+#ifdef CONFIG_CAN
+#include
+#include
+#endif
extern flash_info_t flash_info[]; /* FLASH chips info */
@@ -447,6 +451,19 @@ int board_early_init_r (void)
#endif /* CONFIG_PS2MULT */
+#if defined(CONFIG_CAN_DRIVER) && defined(CONFIG_CAN)
+static struct can_dev tqm8xx_can[2];
+
+#ifdef CONFIG_BOARD_EARLY_INIT_R
+int board_early_init_r (void)
+{
+ i82527_register (&tqm8xx_can[0], CONFIG_SYS_CAN_BASE);
+ i82527_register( &tqm8xx_can[1], CONFIG_SYS_CAN_BASE + 0x100);
+
+ return (0);
+}
+#endif
+#endif
#ifdef CONFIG_MISC_INIT_R
extern void load_sernum_ethaddr(void);
diff --git a/include/configs/TQM855L.h b/include/configs/TQM855L.h
index 1255928..1603d30 100644
--- a/include/configs/TQM855L.h
+++ b/include/configs/TQM855L.h
@@ -88,7 +88,13 @@
#defineCONFIG_STATUS_LED 1 /* Status LED enabled
*/
-#undef CONFIG_CAN_DRIVER /* CAN Driver support disabled */
+#defineCONFIG_CAN_DRIVER /* CAN Driver support
enabled */
+#ifdef CONFIG_CAN_DRIVER
+#define CONFIG_CAN
+#define CONFIG_CAN_I82527
+#define CONFIG_CMD_CAN
+#define CONFIG_BOARD_EARLY_INIT_R
+#endif
/*
* BOOTP options
--
1.6.2.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-sh
Hi,
2009/11/1 Wolfgang Denk :
>
> Done, thanks.
>
Thank you.
>
> Do I understand correctly that "Update lowlevel_init.S of espt-giga"
> obsoletes the patch "Fix build of sh7785lcr 32bit mode" of Mon, 24 Aug
> 2009 11:01:41 +0900 (which was marked as still open in my list) ?
>
>
Yes.
patch "Update lowlevel_init.S of espt-giga" picked up a part of espt-giga
from patch "Fix build of sh7785lcr 32bit mode".
I decided to take the main change of patch "Fix build of sh7785lcr
32bit mode" in next release.
Best regards,
Nobuhiro
--
Nobuhiro Iwamatsu / Debian Developer
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add I2C multibus support for OMAP2/3 boards
Dirk Behme wrote: > Tom Rix wrote: >> From: Syed Mohammed Khasim >> >> This was cherry-picked from >> >> repo: http://www.beagleboard.org/u-boot-arm.git >> commit: 52eddcd07c2e7ad61d15bab2cf2d0d21466eaca2 >> >> In addition to adding multibus support, this patch >> also cleans up the register access. The register >> access has been changed from #defines to a structure. > > Have you looked at my proposal I sent some hours before your patch? Sorry. I did not. Not surprisingly it looks similar. The formatting changes you mentioned were part of the original cherry-picked commit. I tried to leave as much of the original commit intact as possible. I ran but ignored the output of checkpatch.. The biggest complaint it has is with 80 char lines. I looked over your patch. It looks like an improvement to mine. I'm all for dropping mine and using yours. I will run test yours. Do you have a zippy board that you can use to test the 2nd bus ? Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 02/10] USB add macros for debugging usb device setup.
On Saturday 31 October 2009 22:00:09 Tom wrote:
> Mike Frysinger wrote:
> > On Saturday 31 October 2009 13:37:39 Tom Rix wrote:
> >> +#ifdef DEBUG
> >> +static inline void print_device_descriptor(struct usb_device_descriptor
> >> *d) +{
> >> + serial_printf("usb device descriptor \n");
> >
> > do you really need serial_printf() ? what's wrong with debug() ? then
> > you dont even really need "#ifdef DEBUG" around all the functions ...
>
> The explicit serial_printf is done because this patch set changes the
> stdin and stdout for serial to usbtty.
>
> When you use printf to debug printf, you regress into a bad state.
so in your specific use case it makes sense *some* of the time (usbtty is
enabled and the console has been changed to it), but in the general use case
(usb debugging), it does not. why not make it intelligent instead of
penalizing everyone to use their serial console:
- default to debug()
- if usbtty support is enabled, check the current stdout console to see if
it's set to a usbtty, and only then fall back to forcing serial_printf()
-mike
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 08/10] OMAP3 zoom2 Use usbtty if the debug board is not connected.
On Saturday 31 October 2009 22:03:45 Tom wrote:
> Mike Frysinger wrote:
> > On Saturday 31 October 2009 13:37:45 Tom Rix wrote:
> >> + } else {
> >> + usbtty_putc(c);
> >>}
> >
> > dont need those braces (same goes for a few other hunks here)
> > -mike
>
> This is done because if-statement above use braces.
> If this was a simple
> if (foo)
> smt_1
> else
> smt_2
>
> I would have not use braces.
the trailing "else" clause is one statement. the relationship to the previous
if section doesnt matter. common style convention is:
if (foo) {
statement_1;
statement_2;
} else
statement_3;
-mike
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 09/10] OMAP3 USB Initialize twl4030 only if required
On Saturday 31 October 2009 22:09:05 Tom wrote:
> Mike Frysinger wrote:
> > On Saturday 31 October 2009 13:37:46 Tom Rix wrote:
> >> OMAP3EVM uses ISP1504 phy and so twl4030 related init is not required.
> >>
> >> --- a/drivers/usb/musb/omap3.c
> >> +++ b/drivers/usb/musb/omap3.c
> >> @@ -94,12 +94,17 @@ int musb_platform_init(void)
> >>if (platform_needs_initialization) {
> >>u32 stdby;
> >>
> >> + /*
> >> + * OMAP3EVM uses ISP1504 phy and so
> >> + * twl4030 related init is not required.
> >> + */
> >> +#ifdef CONFIG_TWL4030_USB
> >>if (twl4030_usb_ulpi_init()) {
> >>serial_printf("ERROR: %s Could not initialize PHY\n",
> >>__PRETTY_FUNCTION__);
> >>goto end;
> >>}
> >> -
> >> +#endif
> >
> > shouldnt this be abstracted away (weaks/phy-common name/etc...) instead
> > of sprinkling ifdef's everywhere ?
>
> I do not think this change has spinkled if-defs' everywhere
it always starts out as "just one" :P
> As far as I know only the omap3_evm does not use a twl4030.
> There is no sense making this more complicated than an if-def.
this isnt common musb code, so i wont complain about proper architecture here
as it doesnt affect me.
-mike
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mkconfig: deny messed up ARCH definition
On Saturday 31 October 2009 18:20:06 Menon, Nishanth wrote: > From: Mike Frysinger > > On Saturday 31 October 2009 10:12:01 Nishanth Menon wrote: > > > +if [ ! -z "$ARCH" -a "$ARCH" != "$2" ]; then > > > > is the !-z really needed ? > > We don't want the check to trigger if ARCH is not defined. > [ "$ARCH" != "$2" ] will trigger as "" != "arm" the implied question is whether this is a valid state. i know you dont want that kind of comparison, but i thought the Makefile would have set it up for you by default. now that i think about it a bit more, that isnt what happens at all. so only thing to change here is to use -n and not !-z -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 02/10] USB add macros for debugging usb device setup.
Mike Frysinger wrote:
> On Saturday 31 October 2009 22:00:09 Tom wrote:
>> Mike Frysinger wrote:
>>> On Saturday 31 October 2009 13:37:39 Tom Rix wrote:
+#ifdef DEBUG
+static inline void print_device_descriptor(struct usb_device_descriptor
*d) +{
+ serial_printf("usb device descriptor \n");
>>> do you really need serial_printf() ? what's wrong with debug() ? then
>>> you dont even really need "#ifdef DEBUG" around all the functions ...
>> The explicit serial_printf is done because this patch set changes the
>> stdin and stdout for serial to usbtty.
>>
>> When you use printf to debug printf, you regress into a bad state.
>
> so in your specific use case it makes sense *some* of the time (usbtty is
> enabled and the console has been changed to it), but in the general use case
> (usb debugging), it does not. why not make it intelligent instead of
> penalizing everyone to use their serial console:
> - default to debug()
> - if usbtty support is enabled, check the current stdout console to see if
> it's set to a usbtty, and only then fall back to forcing serial_printf()
> -mike
A better solution would be to combine this logic into debug().
Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 02/10] USB add macros for debugging usb device setup.
On Sunday 01 November 2009 09:02:22 Tom wrote:
> Mike Frysinger wrote:
> > On Saturday 31 October 2009 22:00:09 Tom wrote:
> >> Mike Frysinger wrote:
> >>> On Saturday 31 October 2009 13:37:39 Tom Rix wrote:
> +#ifdef DEBUG
> +static inline void print_device_descriptor(struct
> usb_device_descriptor *d) +{
> +serial_printf("usb device descriptor \n");
> >>>
> >>> do you really need serial_printf() ? what's wrong with debug() ? then
> >>> you dont even really need "#ifdef DEBUG" around all the functions ...
> >>
> >> The explicit serial_printf is done because this patch set changes the
> >> stdin and stdout for serial to usbtty.
> >>
> >> When you use printf to debug printf, you regress into a bad state.
> >
> > so in your specific use case it makes sense *some* of the time (usbtty is
> > enabled and the console has been changed to it), but in the general use
> > case (usb debugging), it does not. why not make it intelligent instead
> > of penalizing everyone to use their serial console:
> > - default to debug()
> > - if usbtty support is enabled, check the current stdout console to see
> > if it's set to a usbtty, and only then fall back to forcing
> > serial_printf()
>
> A better solution would be to combine this logic into debug().
yes and no. debug() should not change, but a new debug function would
probably make sense. debug_stdio() where the first argument would be the
device name you're debugging ("usbtty" here) and would handle sending directly
to the serial functions if current stdio is set to that.
i look forward to your proposed code ;)
-mike
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 08/10] OMAP3 zoom2 Use usbtty if the debug board is not connected.
Mike Frysinger wrote:
> On Saturday 31 October 2009 22:03:45 Tom wrote:
>> Mike Frysinger wrote:
>>> On Saturday 31 October 2009 13:37:45 Tom Rix wrote:
+ } else {
+ usbtty_putc(c);
}
>>> dont need those braces (same goes for a few other hunks here)
>>> -mike
>> This is done because if-statement above use braces.
>> If this was a simple
>> if (foo)
>> smt_1
>> else
>> smt_2
>>
>> I would have not use braces.
>
> the trailing "else" clause is one statement. the relationship to the
> previous
> if section doesnt matter. common style convention is:
> if (foo) {
> statement_1;
> statement_2;
> } else
> statement_3;
> -mike
Please see
http://www.kernel.org/doc/Documentation/CodingStyle
Do not unnecessarily use braces where a single statement will do.
if (condition)
action();
This does not apply if one branch of a conditional statement is a single
statement. Use braces in both branches.
if (condition) {
do_this();
do_that();
} else {
otherwise();
}
Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 02/10] USB add macros for debugging usb device setup.
Mike Frysinger wrote:
> On Sunday 01 November 2009 09:02:22 Tom wrote:
>> Mike Frysinger wrote:
>>> On Saturday 31 October 2009 22:00:09 Tom wrote:
Mike Frysinger wrote:
> On Saturday 31 October 2009 13:37:39 Tom Rix wrote:
>> +#ifdef DEBUG
>> +static inline void print_device_descriptor(struct
>> usb_device_descriptor *d) +{
>> +serial_printf("usb device descriptor \n");
> do you really need serial_printf() ? what's wrong with debug() ? then
> you dont even really need "#ifdef DEBUG" around all the functions ...
The explicit serial_printf is done because this patch set changes the
stdin and stdout for serial to usbtty.
When you use printf to debug printf, you regress into a bad state.
>>> so in your specific use case it makes sense *some* of the time (usbtty is
>>> enabled and the console has been changed to it), but in the general use
>>> case (usb debugging), it does not. why not make it intelligent instead
>>> of penalizing everyone to use their serial console:
>>> - default to debug()
>>> - if usbtty support is enabled, check the current stdout console to see
>>> if it's set to a usbtty, and only then fall back to forcing
>>> serial_printf()
>> A better solution would be to combine this logic into debug().
>
> yes and no. debug() should not change, but a new debug function would
> probably make sense. debug_stdio() where the first argument would be the
> device name you're debugging ("usbtty" here) and would handle sending
> directly
> to the serial functions if current stdio is set to that.
>
> i look forward to your proposed code ;)
This patch is not critical to the patchset.
It would be easier for me to remove it.
Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC 1/5] CAN interface library
On Sunday 01 November 2009 06:33:33 Wolfgang Grandegger wrote:
> --- a/Makefile
> +++ b/Makefile
> @@ -203,6 +203,7 @@ LIBS += net/libnet.a
> LIBS += disk/libdisk.a
> LIBS += drivers/bios_emulator/libatibiosemu.a
> LIBS += drivers/block/libblock.a
> +LIBS += drivers/can/libcan.a
this isnt an issue specific to CAN, but i wonder if we should switch LIBS to
LIBS-y now that the top level Makefile can rely on autoconf.mk settings after
the point config.mk is included. it would save time on pointlessly recursing
into all the empty dirs and creating empty archives.
> --- /dev/null
> +++ b/drivers/can/Makefile
> @@ -0,0 +1,47 @@
> +include $(TOPDIR)/config.mk
> +
> +LIB := $(obj)libcan.a
> +
> +COBJS-$(CONFIG_CAN) += can.o
> +
> +COBJS:= $(COBJS-y)
> +SRCS := $(COBJS:.o=.c)
> +OBJS := $(addprefix $(obj),$(COBJS))
> +
> +all: $(LIB)
> +
> +$(LIB): $(obj).depend $(OBJS)
> + $(AR) $(ARFLAGS) $@ $(OBJS)
> +
> +
> +#
> +
> +# defines $(obj).depend target
> +include $(SRCTREE)/rules.mk
> +
> +sinclude $(obj).depend
> +
> +
also not specific to CAN, but i think it's time we start creating .mk files
for subdirs to include
> --- /dev/null
> +++ b/drivers/can/can.c
>
> +static char *baudrates[] = { "125K", "250K", "500K" };
so we're restricting ourselves to these three speeds ? i have passing
familiarity with CAN, but i didnt think the protocol was restricted to
specific speeds.
> +int can_register (struct can_dev* can_dev)
no space before the paren, and the * is cuddled on the wrong side of the
space. seems like a lot of this code suffers from these two issues.
> +{
> + struct can_dev* dev;
> +
> + can_dev->next = NULL;
> + if (!can_devs)
> + can_devs = can_dev;
> + else {
> + for (dev = can_devs; dev->next; dev = dev->next)
> + ;
> + dev->next = can_dev;
> + }
invert the if logic and i think the code would look "nicer" -- use braces on
the first branch instead of the second.
> +struct can_dev *can_init (int dev_num, int ibaud)
> +{
> + struct can_dev *dev;
> + int i;
> +
> + if (!can_devs) {
> + puts ("No CAN devices registered\n");
> + return NULL;
> + }
> +
> + /* Advance to selected device */
> + for (i = 0, dev = can_devs; dev; i++, dev = dev->next) {
> + if (i == dev_num)
> + break;
> + }
> +
> + if (!dev) {
> + printf ("CAN device %d does not exist\n", dev_num);
> + return NULL;
> + }
> +
> + printf ("Initializing CAN%d at 0x%08x with baudrate %s\n",
> + i, dev->base, baudrates[ibaud]);
> +
> + dev->init (dev, ibaud);
> +
> + return dev;
> +}
wonder if we should have a generic device list code base since this looks
similar to a lot of other u-boot device lists ...
> --- /dev/null
> +++ b/include/can.h
> @@ -0,0 +1,70 @@
> +/*
> + * (C) Copyright 2007-2009, Wolfgang Grandegger
have you really been working on this stuff since 2007 ?
> +struct can_dev {
> + char *name;
const ?
-mike
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC 2/5] CAN device test command
On Sunday 01 November 2009 06:33:34 Wolfgang Grandegger wrote:
> + if (op == 's') {
> + else if (op == 'i') {
> + else if (op == 'r') {
> + } else if (op == 'x') {
> + } else {
your if style here is inconsistent, but ignoring that, shouldnt this really be
a switch() ? although, by only checking the first char, you allow people to
encode typos into their commands and not realize it until some point in the
future where things get stricter. i.e. people can do `can ilovecandy ...`
> + unsigned int dev_num = 0, ibaud = 0;
> + struct can_dev *dev;
> +
> + if (argc > 2)
> + dev_num = simple_strtoul (argv[2], NULL, 10);
> + if (argc > 3) {
> + ibaud = simple_strtoul (argv[3], NULL, 10);
> + if (ibaud > 2)
> + ibaud = 2;
> + }
> + dev = can_init (dev_num, ibaud);
> + if (!dev)
> + return 1;
> + can_dev = dev;
if i told CAN to init an unknown device, i would expect to get an error and
the command state to remain in said error state until i selected a proper CAN
device. otherwise, a script that didnt check the can init status would
incorrectly operate on the previously selected can device.
how do other commands work ? am i complaining about common convention here ?
> + printf ("Usage:\n%s\n", cmdtp->usage);
cmd_usage() ?
> + can, 3, 1, do_can,
> + "can - CAN bus commands\n",
> + "can status [level]\n"
> + "can init [dev] [baud-index]\n"
> + "can xmit [id] [d0] [d1] ... [d7]\n"
> + "can recv, abort with CTRL-C\n"
does the help really display correctly here ? i think the "can status" line
will have too many "can"'s ?
-mike
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 08/10] OMAP3 zoom2 Use usbtty if the debug board is not connected.
On Sunday 01 November 2009 09:14:48 Tom wrote:
> Mike Frysinger wrote:
> > On Saturday 31 October 2009 22:03:45 Tom wrote:
> >> Mike Frysinger wrote:
> >>> On Saturday 31 October 2009 13:37:45 Tom Rix wrote:
> +} else {
> +usbtty_putc(c);
> }
> >>>
> >>> dont need those braces (same goes for a few other hunks here)
> >>
> >> This is done because if-statement above use braces.
> >> If this was a simple
> >> if (foo)
> >>smt_1
> >> else
> >>smt_2
> >>
> >> I would have not use braces.
> >
> > the trailing "else" clause is one statement. the relationship to the
> > previous if section doesnt matter. common style convention is:
> > if (foo) {
> > statement_1;
> > statement_2;
> > } else
> > statement_3;
>
> Please see
>
> http://www.kernel.org/doc/Documentation/CodingStyle
>
> Do not unnecessarily use braces where a single statement will do.
>
> if (condition)
> action();
>
> This does not apply if one branch of a conditional statement is a single
> statement. Use braces in both branches.
>
> if (condition) {
> do_this();
> do_that();
> } else {
> otherwise();
> }
i guess i go by what people are actually accepting at LKML. braces get
stripped from single if statements all the time. i dont really care the much
since it isnt my code, so if you want to include the cruft anyways, that's
your choice.
-mike
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mkconfig: deny messed up ARCH definition
Dear Mike Frysinger, In message <200911010838.08938.vap...@gentoo.org> you wrote: > > > > > +if [ ! -z "$ARCH" -a "$ARCH" != "$2" ]; then > > > > > > is the !-z really needed ? > > > > We don't want the check to trigger if ARCH is not defined. > > [ "$ARCH" != "$2" ] will trigger as "" != "arm" > > the implied question is whether this is a valid state. i know you dont wan> > t > that kind of comparison, but i thought the Makefile would have set it up fo> > r > you by default. now that i think about it a bit more, that isnt what happe> > ns > at all. > > so only thing to change here is to use -n and not !-z Or even omit the (redundant) "-n" and just write if [ "$ARCH" -a "$ARCH" != "$2" ]; then ... Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Use the Force, Luke. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC 1/5] CAN interface library
Mike Frysinger wrote:
> On Sunday 01 November 2009 06:33:33 Wolfgang Grandegger wrote:
[snip]
>> --- /dev/null
>> +++ b/drivers/can/can.c
>>
>> +static char *baudrates[] = { "125K", "250K", "500K" };
>
> so we're restricting ourselves to these three speeds ? i have passing
> familiarity with CAN, but i didnt think the protocol was restricted to
> specific speeds.
Well, this is an RFC and as I wrote in the introduction some features
need to be added or extended, especially for CAN device configuration.
My idea is to have a more complete default bit-timing table, which board
specific code may overwrite using, for example:
sja1000_register(&my_sja1000, &my_config_opts);
This would also allow to set the CAN clock, cdr and ocr registers.
>> +int can_register (struct can_dev* can_dev)
>
> no space before the paren, and the * is cuddled on the wrong side of the
> space. seems like a lot of this code suffers from these two issues.
U-Boot coding style requires a space after the function name and before
"(". But the "*" is misplaced, of course.
>> +{
>> +struct can_dev* dev;
>> +
>> +can_dev->next = NULL;
>> +if (!can_devs)
>> +can_devs = can_dev;
>> +else {
>> +for (dev = can_devs; dev->next; dev = dev->next)
>> +;
>> +dev->next = can_dev;
>> +}
>
> invert the if logic and i think the code would look "nicer" -- use braces on
> the first branch instead of the second.
OK.
>> +struct can_dev *can_init (int dev_num, int ibaud)
>> +{
>> +struct can_dev *dev;
>> +int i;
>> +
>> +if (!can_devs) {
>> +puts ("No CAN devices registered\n");
>> +return NULL;
>> +}
>> +
>> +/* Advance to selected device */
>> +for (i = 0, dev = can_devs; dev; i++, dev = dev->next) {
>> +if (i == dev_num)
>> +break;
>> +}
>> +
>> +if (!dev) {
>> +printf ("CAN device %d does not exist\n", dev_num);
>> +return NULL;
>> +}
>> +
>> +printf ("Initializing CAN%d at 0x%08x with baudrate %s\n",
>> +i, dev->base, baudrates[ibaud]);
>> +
>> +dev->init (dev, ibaud);
>> +
>> +return dev;
>> +}
>
> wonder if we should have a generic device list code base since this looks
> similar to a lot of other u-boot device lists ...
Do we already have a generic interface?
>> --- /dev/null
>> +++ b/include/can.h
>> @@ -0,0 +1,70 @@
>> +/*
>> + * (C) Copyright 2007-2009, Wolfgang Grandegger
>
> have you really been working on this stuff since 2007 ?
The code was written in 2007. "2007, 2009" is more appropriate.
>> +struct can_dev {
>> +char *name;
>
> const ?
OK.
Wolfgang.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC 2/5] CAN device test command
Mike Frysinger wrote:
> On Sunday 01 November 2009 06:33:34 Wolfgang Grandegger wrote:
>> +if (op == 's') {
>> +else if (op == 'i') {
>> +else if (op == 'r') {
>> +} else if (op == 'x') {
>> +} else {
>
> your if style here is inconsistent, but ignoring that, shouldnt this really
> be
> a switch() ? although, by only checking the first char, you allow people to
> encode typos into their commands and not realize it until some point in the
> future where things get stricter. i.e. people can do `can ilovecandy ...`
Will fix.
>> +unsigned int dev_num = 0, ibaud = 0;
>> +struct can_dev *dev;
>> +
>> +if (argc > 2)
>> +dev_num = simple_strtoul (argv[2], NULL, 10);
>> +if (argc > 3) {
>> +ibaud = simple_strtoul (argv[3], NULL, 10);
>> +if (ibaud > 2)
>> +ibaud = 2;
>> +}
>> +dev = can_init (dev_num, ibaud);
>> +if (!dev)
>> +return 1;
>> +can_dev = dev;
>
> if i told CAN to init an unknown device, i would expect to get an error and
> the command state to remain in said error state until i selected a proper CAN
> device. otherwise, a script that didnt check the can init status would
> incorrectly operate on the previously selected can device.
can_init will already print an error message. But that might be changed.
> how do other commands work ? am i complaining about common convention here ?
>
>> +printf ("Usage:\n%s\n", cmdtp->usage);
>
> cmd_usage() ?
OK.
>> +can, 3, 1, do_can,
>> +"can - CAN bus commands\n",
>> +"can status [level]\n"
>> +"can init [dev] [baud-index]\n"
>> +"can xmit [id] [d0] [d1] ... [d7]\n"
>> +"can recv, abort with CTRL-C\n"
>
> does the help really display correctly here ? i think the "can status" line
> will have too many "can"'s ?
I think the output was OK. But I will check later next week.
Note that this is a RFC trying to discuss the real requirements of a CAN
interface in U-Boot. I think it would also be nice to have can_xmit()
and can_recv() with a timeout parameter, e.g.:
can_xmit(struct can_dev *dev, int timeout_us);
And maybe also a can_xmit_done() function.
Wolfgang.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add I2C multibus support for OMAP2/3 boards
Tom wrote: > Dirk Behme wrote: >> Tom Rix wrote: >>> From: Syed Mohammed Khasim >>> >>> This was cherry-picked from >>> >>> repo: http://www.beagleboard.org/u-boot-arm.git >>> commit: 52eddcd07c2e7ad61d15bab2cf2d0d21466eaca2 >>> >>> In addition to adding multibus support, this patch >>> also cleans up the register access. The register >>> access has been changed from #defines to a structure. >> Have you looked at my proposal I sent some hours before your patch? > > Sorry. I did not. > Not surprisingly it looks similar. > > The formatting changes you mentioned were part of the original > cherry-picked commit. I tried to leave as much of the original > commit intact as possible. I ran but ignored the output of > checkpatch.. The biggest complaint it has is with 80 char lines. > > I looked over your patch. > It looks like an improvement to mine. > > I'm all for dropping mine and using yours. > I will run test yours. > > Do you have a zippy board that you can use to test the 2nd bus ? > Dirk, Some feedback. No regressions on MAKEALL arm I ran tested your patch Zoom1 and Beagle. Default i2c looks good. I did not test the multibus support. Looks good, please officially submit your patch. Tom > Tom > ___ > 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] [RFC 1/5] CAN interface library
On Sunday 01 November 2009 11:16:59 Wolfgang Grandegger wrote:
> Mike Frysinger wrote:
> > On Sunday 01 November 2009 06:33:33 Wolfgang Grandegger wrote:
> >> --- /dev/null
> >> +++ b/drivers/can/can.c
> >>
> >> +static char *baudrates[] = { "125K", "250K", "500K" };
> >
> > so we're restricting ourselves to these three speeds ? i have passing
> > familiarity with CAN, but i didnt think the protocol was restricted to
> > specific speeds.
>
> Well, this is an RFC and as I wrote in the introduction some features
> need to be added or extended, especially for CAN device configuration.
> My idea is to have a more complete default bit-timing table, which board
> specific code may overwrite using, for example:
>
>sja1000_register(&my_sja1000, &my_config_opts);
>
> This would also allow to set the CAN clock, cdr and ocr registers.
this makes sense if the device supports a limited number of baud rates. but
what if the baud rate is arbitrary (between two limits) ?
> >> +int can_register (struct can_dev* can_dev)
> >
> > no space before the paren, and the * is cuddled on the wrong side of the
> > space. seems like a lot of this code suffers from these two issues.
>
> U-Boot coding style requires a space after the function name and before
> "(". But the "*" is misplaced, of course.
it's (thankfully) been changing to Linux kernel style
> >> +struct can_dev *can_init (int dev_num, int ibaud)
> >
> > wonder if we should have a generic device list code base since this looks
> > similar to a lot of other u-boot device lists ...
>
> Do we already have a generic interface?
i dont think so
> >> --- /dev/null
> >> +++ b/include/can.h
> >> @@ -0,0 +1,70 @@
> >> +/*
> >> + * (C) Copyright 2007-2009, Wolfgang Grandegger
> >
> > have you really been working on this stuff since 2007 ?
>
> The code was written in 2007. "2007, 2009" is more appropriate.
the intro made it sound like this was a recent development (i.e. last few
days/weeks). if code is actually from 2007, then the range is fine.
-mike
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC 2/5] CAN device test command
On Sunday 01 November 2009 11:24:59 Wolfgang Grandegger wrote: > Note that this is a RFC trying to discuss the real requirements of a CAN > interface in U-Boot. I think it would also be nice to have can_xmit() > and can_recv() with a timeout parameter, e.g.: > > can_xmit(struct can_dev *dev, int timeout_us); > > And maybe also a can_xmit_done() function. i only have a passing familiarity with CAN (havent done real work with it), but i can find someone to look over the current stuff -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Enabling 2 FCC ports using CONFIG_NET_MULT I
hi , Manually i am setting the MAC address using setenv ethaddr MAC Address for each FCC. i am using FCC1 & FCC2. i want one FCC port to be active at a time. PowerPC is MPC8280 Regards, Gurumurthy___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH-ARM 1/3] Add support for the s3c2440 cpu excluding nand driver
This patch adds support for the s3c2440 cpu, excluding the nand driver. Tested on an Embest SBC2440-II Board with local u-boot patches as I don't have any s3c2400 or s3c2410 boards but need this patch applying before I can submit patches for the SBC2440-II Board. Also, ran MAKEALL for all ARM9 targets and no new warnings or errors were found. Note that checkpatch.pl shows one error: ERROR: Invalid UTF-8, patch and commit message should be encoded in UTF-8 #656: FILE: include/s3c2440.h:3: + * David M�ller ELSOFT AG Switzerland. d.muel...@elsoft.ch ^ As David's name correctly contains a non-UTF-8 character I've ignored this error. Signed-off-by: Kevin Morfitt --- common/serial.c |4 +- cpu/arm920t/s3c24x0/Makefile |6 +- cpu/arm920t/s3c24x0/arch_pre_lowlevel_init.S | 81 + cpu/arm920t/s3c24x0/speed.c | 41 +-- cpu/arm920t/s3c24x0/timer.c | 19 +--- cpu/arm920t/s3c24x0/usb.c| 17 +-- cpu/arm920t/s3c24x0/usb_ohci.c | 11 +-- cpu/arm920t/start.S | 39 +-- drivers/i2c/s3c24x0_i2c.c| 18 ++-- drivers/mtd/nand/s3c2410_nand.c |2 +- drivers/rtc/s3c24x0_rtc.c|7 +- drivers/serial/serial_s3c24x0.c |6 +- drivers/usb/host/ohci-hcd.c |3 +- include/common.h |5 +- include/configs/VCMA9.h |4 +- include/configs/sbc2410x.h |4 +- include/configs/smdk2400.h |4 +- include/configs/smdk2410.h |4 +- include/configs/trab.h |4 +- include/s3c2410.h| 25 include/s3c2440.h| 163 ++ include/s3c24x0.h| 94 ++- include/s3c24x0_cpu.h| 29 + 23 files changed, 471 insertions(+), 119 deletions(-) create mode 100644 cpu/arm920t/s3c24x0/arch_pre_lowlevel_init.S create mode 100644 include/s3c2440.h create mode 100644 include/s3c24x0_cpu.h diff --git a/common/serial.c b/common/serial.c index 5f9ffd7..52b3055 100644 --- a/common/serial.c +++ b/common/serial.c @@ -59,7 +59,7 @@ struct serial_device *__default_serial_console (void) #else return &serial0_device; #endif -#elif defined(CONFIG_S3C2410) +#elif defined(CONFIG_S3C2410) || defined(CONFIG_S3C2440) #if defined(CONFIG_SERIAL1) return &s3c24xx_serial0_device; #elif defined(CONFIG_SERIAL2) @@ -148,7 +148,7 @@ void serial_initialize (void) #if defined (CONFIG_STUART) serial_register(&serial_stuart_device); #endif -#if defined(CONFIG_S3C2410) +#if defined(CONFIG_S3C2410) || defined(CONFIG_S3C2440) serial_register(&s3c24xx_serial0_device); serial_register(&s3c24xx_serial1_device); serial_register(&s3c24xx_serial2_device); diff --git a/cpu/arm920t/s3c24x0/Makefile b/cpu/arm920t/s3c24x0/Makefile index 7e8d6ed..406f881 100644 --- a/cpu/arm920t/s3c24x0/Makefile +++ b/cpu/arm920t/s3c24x0/Makefile @@ -25,6 +25,8 @@ include $(TOPDIR)/config.mk LIB= $(obj)lib$(SOC).a +SOBJS-$(CONFIG_DO_ARCH_PRE_LOWLEVEL_INIT) += arch_pre_lowlevel_init.o + COBJS-$(CONFIG_USE_IRQ) += interrupts.o COBJS-y+= speed.o COBJS-y+= timer.o @@ -32,8 +34,8 @@ COBJS-y += usb.o COBJS-y+= usb_ohci.o -SRCS := $(SOBJS:.o=.S) $(COBJS-y:.o=.c) -OBJS := $(addprefix $(obj),$(SOBJS) $(COBJS-y)) +SRCS := $(SOBJS-y:.o=.S) $(COBJS-y:.o=.c) +OBJS := $(addprefix $(obj),$(SOBJS-y) $(COBJS-y)) all: $(obj).depend $(LIB) diff --git a/cpu/arm920t/s3c24x0/arch_pre_lowlevel_init.S b/cpu/arm920t/s3c24x0/arch_pre_lowlevel_init.S new file mode 100644 index 000..13467cf --- /dev/null +++ b/cpu/arm920t/s3c24x0/arch_pre_lowlevel_init.S @@ -0,0 +1,81 @@ +/* + * (C) Copyright 2009 + * Kevin Morfitt, Fearnside Systems Ltd, + * + * 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 + +#ifdef CONFIG_S3C24X0 + +/* Register addresses. */ +# ifdef CONFIG_S3C2400 + #define pWTCON 0x1530 + #define INTMSK 0x1448 + #de
[U-Boot] [PATCH-ARM 2/3] Add sc32440 support to the s3c2410 nand driver
This patch adds support for the s3c2440 cpu to the nand driver. It does
this by replacing the existing driver with that from linux 2.6.31.5,
modified to make it work in the u-boot mtd nand architecture. Note that
the linux s3c2410 nand driver supports s3c2410 and s3c2440, though I haven't
been able to test this on an s3c2410 board, only an s3c2440 board.
Tested on an Embest SBC2440-II Board with local u-boot patches as I don't have
any s3c2400 or s3c2410 boards but need this patch applying before I can submit
patches for the SBC2440-II Board. Also, ran MAKEALL for all ARM9 targets and no
new warnings or errors were found.
Signed-off-by: Kevin Morfitt
drivers/mtd/nand/s3c2410_nand.c | 134 +--
1 files changed, 73 insertions(+), 61 deletions(-)
diff --git a/drivers/mtd/nand/s3c2410_nand.c b/drivers/mtd/nand/s3c2410_nand.c
index 87d0bf6..b8ea581 100644
--- a/drivers/mtd/nand/s3c2410_nand.c
+++ b/drivers/mtd/nand/s3c2410_nand.c
@@ -2,6 +2,10 @@
* (C) Copyright 2006 OpenMoko, Inc.
* Author: Harald Welte
*
+ * Modified to add S3C2440 support by
+ * (C) Copyright 2009
+ * Kevin Morfitt, Fearnside Systems Ltd,
+ *
* 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
@@ -21,48 +25,53 @@
#include
#include
+#include
#include
#include
-#define S3C2410_NFCONF_EN (1<<15)
-#define S3C2410_NFCONF_512BYTE (1<<14)
-#define S3C2410_NFCONF_4STEP (1<<13)
-#define S3C2410_NFCONF_INITECC (1<<12)
-#define S3C2410_NFCONF_nFCE(1<<11)
-#define S3C2410_NFCONF_TACLS(x)((x)<<8)
-#define S3C2410_NFCONF_TWRPH0(x) ((x)<<4)
-#define S3C2410_NFCONF_TWRPH1(x) ((x)<<0)
+#if defined(CONFIG_S3C2410_NAND_HWECC) && defined(CONFIG_SYS_NAND_LARGEPAGE)
+/* new oob placement block for use with hardware ecc generation
+ */
+static struct nand_ecclayout nand_hw_eccoob = {
+ .eccbytes = 3,
+ .eccpos = {0, 1, 2},
+ .oobfree = { {8, 8} }
+};
+#endif
-#define S3C2410_ADDR_NALE 4
-#define S3C2410_ADDR_NCLE 8
+static void s3c2410_nand_select_chip(struct mtd_info *mtd, int chip)
+{
+ struct s3c2410_nand *nand = s3c2410_get_base_nand();
+ unsigned long reg = readl(&nand->S3C24X0_NAND_CTRL_REG);
+
+ if (chip == -1) {
+ debugX(1, "Negating nFCE\n");
+ reg |= S3C24X0_NAND_nFCE_BIT;
+ } else {
+ debugX(1, "Asserting nFCE\n");
+ reg &= ~S3C24X0_NAND_nFCE_BIT;
+ }
+ writel(reg, &nand->S3C24X0_NAND_CTRL_REG);
+}
static void s3c2410_hwcontrol(struct mtd_info *mtd, int cmd, unsigned int ctrl)
{
- struct nand_chip *chip = mtd->priv;
struct s3c2410_nand *nand = s3c2410_get_base_nand();
debugX(1, "hwcontrol(): 0x%02x 0x%02x\n", cmd, ctrl);
- if (ctrl & NAND_CTRL_CHANGE) {
- ulong IO_ADDR_W = (ulong)nand;
-
- if (!(ctrl & NAND_CLE))
- IO_ADDR_W |= S3C2410_ADDR_NCLE;
- if (!(ctrl & NAND_ALE))
- IO_ADDR_W |= S3C2410_ADDR_NALE;
-
- chip->IO_ADDR_W = (void *)IO_ADDR_W;
+ if (cmd == NAND_CMD_NONE)
+ return;
- if (ctrl & NAND_NCE)
- writel(readl(&nand->NFCONF) & ~S3C2410_NFCONF_nFCE,
- &nand->NFCONF);
- else
- writel(readl(&nand->NFCONF) | S3C2410_NFCONF_nFCE,
- &nand->NFCONF);
+ if (ctrl & NAND_CLE) {
+ debugX(1, "NFCMD = 0x%08X\n", cmd);
+ writel(cmd, &nand->NFCMD);
}
- if (cmd != NAND_CMD_NONE)
- writeb(cmd, chip->IO_ADDR_W);
+ if (ctrl & NAND_ALE) {
+ debugX(1, "NFADDR = 0x%08X\n", cmd);
+ writel(cmd, &nand->NFADDR);
+ }
}
static int s3c2410_dev_ready(struct mtd_info *mtd)
@@ -76,39 +85,32 @@ static int s3c2410_dev_ready(struct mtd_info *mtd)
void s3c2410_nand_enable_hwecc(struct mtd_info *mtd, int mode)
{
struct s3c2410_nand *nand = s3c2410_get_base_nand();
+ unsigned long reg = readl(&nand->S3C24X0_NAND_CTRL_REG);
+
debugX(1, "s3c2410_nand_enable_hwecc(%p, %d)\n", mtd, mode);
- writel(readl(&nand->NFCONF) | S3C2410_NFCONF_INITECC, &nand->NFCONF);
+ reg |= S3C24X0_NAND_INITECC_BIT;
+ writel(reg, &nand->S3C24X0_NAND_CTRL_REG);
}
static int s3c2410_nand_calculate_ecc(struct mtd_info *mtd, const u_char *dat,
u_char *ecc_code)
{
- ecc_code[0] = NFECC0;
- ecc_code[1] = NFECC1;
- ecc_code[2] = NFECC2;
+ struct s3c2410_nand *nand = s3c2410_get_base_nand();
+ unsigned long ecc = readl(&nand->S3C24X0_NAND_ECC_REG);
+
+ ecc_code[0] = ecc;
+ ecc_code[1] = ecc >> 8;
+ ecc_code[2] = ecc >> 16;
debugX(1,
[U-Boot] [PATCH-ARM 3/3] Add Support for the SBC2440-II Board
This patch adds support for the Embest SBC2440-II Board. Tested on an Embest SBC2440-II Board with local u-boot patches as I don't have any s3c2400 or s3c2410 boards but need this patch applying before I can submit patches for the SBC2440-II Board. Also, ran MAKEALL for all ARM9 targets and no new warnings or errors were found. Signed-off-by: Kevin Morfitt --- MAINTAINERS|4 + MAKEALL|1 + 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 | 122 +++ cpu/arm920t/s3c24x0/timer.c|1 + include/configs/sbc2440ii.h| 254 9 files changed, 684 insertions(+), 0 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 include/configs/sbc2440ii.h diff --git a/MAINTAINERS b/MAINTAINERS index d70a9d2..65f8dfe 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -638,6 +638,10 @@ Nishanth Menon omap3_sdp3430 ARM CORTEX-A8 (OMAP3xx SoC) omap3_zoom1 ARM CORTEX-A8 (OMAP3xx SoC) +Kevin Morfitt + + sbc2440ii ARM920T + David Müller smdk2410ARM920T diff --git a/MAKEALL b/MAKEALL index 5492d8f..c84b23e 100755 --- a/MAKEALL +++ b/MAKEALL @@ -552,6 +552,7 @@ LIST_ARM9=" \ openrd_base \ rd6281a \ sbc2410x\ + sbc2440ii \ scb9328 \ sheevaplug \ smdk2400\ diff --git a/Makefile b/Makefile index b91b1c0..a6619e5 100644 --- a/Makefile +++ b/Makefile @@ -3020,6 +3020,9 @@ rd6281a_config: unconfig sbc2410x_config: unconfig @$(MKCONFIG) $(@:_config=) arm arm920t sbc2410x NULL s3c24x0 +sbc2440ii_config: unconfig + @$(MKCONFIG) $(@:_config=) arm arm920t sbc2440ii embest s3c24x0 + scb9328_config : unconfig @$(MKCONFIG) $(@:_config=) arm arm920t scb9328 NULL imx diff --git a/board/embest/sbc2440ii/Makefile b/board/embest/sbc2440ii/Makefile new file mode 100644 index 000..26237a2 --- /dev/null +++ b/board/embest/sbc2440ii/Makefile @@ -0,0 +1,55 @@ +# +# (C) Copyright 2000-2006 +# Wolfgang Denk, DENX Software Engineering, w...@denx.de. +# +# Modified for EMBEST SBC2440-II board with S3C2440 (ARM920T) cpu 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 $(TOPDIR)/config.mk + +LIB = $(obj)lib$(BOARD).a + +COBJS := sbc2440ii.o +SOBJS := lowlevel_init.o + +SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS)) +SOBJS := $(addprefix $(obj),$(SOBJS)) + +$(LIB): $(obj).depend $(OBJS) $(SOBJS) + $(AR) $(ARFLAGS) $@ $(OBJS) $(SOBJS) + +clean: + rm -f $(SOBJS) $(OBJS) + +distclean: clean + rm -f $(LIB) core *.bak $(obj).depend + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/board/embest/sbc2440ii/config.mk b/board/embest/sbc2440ii/config.mk new file mode 100644 index 000..def11d8 --- /dev/null +++ b/board/embest/sbc2440ii/config.mk @@ -0,0 +1,25 @@ +# +# (C) Copyright 2002 +# Gary Jennejohn, DENX Software Engineering, +# David Mueller, ELSOFT AG, +# +# SAMSUNG SMDK2410 board with S3C2410X (ARM920T) cpu +# +# see http://www.samsung.com/ for more information on SAMSUNG +# +# Modified for EMBEST SBC2440-II board with S3C2440 (ARM920T) cpu by: +# (C) Copyright 2009 +# Kevin Morfitt, Fearnside Systems Ltd, + +# +# SBC2440-II has 1 bank of 64 MB DRAM +# +# 3000' to 3800' +# +# Linux-Kernel is expected to be at 3000'8000, entry 3000'8000 +# +# we load ourself to 33F8' +#
[U-Boot] [PATCH] ARM: fix build error with gcc-4.4.2 about inline function declared weak
From: Abdoulaye Walsimou Gaye
This patch fix build error with gcc-4.4.2 about inline function
declared weak, see below:
board.c:96: error: inline function 'coloured_LED_init' cannot be declared weak
board.c:98: error: inline function 'red_LED_on' cannot be declared weak
board.c:100: error: inline function 'red_LED_off' cannot be declared weak
board.c:102: error: inline function 'green_LED_on' cannot be declared weak
board.c:104: error: inline function 'green_LED_off' cannot be declared weak
board.c:106: error: inline function 'yellow_LED_on' cannot be declared weak
board.c:108: error: inline function 'yellow_LED_off' cannot be declared weak
board.c:110: error: inline function 'blue_LED_on' cannot be declared weak
board.c:112: error: inline function 'blue_LED_off' cannot be declared weak
make[1]: *** [board.o] Error 1
Signed-off-by: Abdoulaye Walsimou Gaye
---
lib_arm/board.c | 18 +-
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/lib_arm/board.c b/lib_arm/board.c
index 5e3d7f6..886c74c 100644
--- a/lib_arm/board.c
+++ b/lib_arm/board.c
@@ -93,23 +93,23 @@ extern void rtl8019_get_enetaddr (uchar * addr);
* May be supplied by boards if desired
*/
void inline __coloured_LED_init (void) {}
-void inline coloured_LED_init (void) __attribute__((weak,
alias("__coloured_LED_init")));
+void coloured_LED_init(void)__attribute__((weak,
alias("__coloured_LED_init")));
void inline __red_LED_on (void) {}
-void inline red_LED_on (void) __attribute__((weak, alias("__red_LED_on")));
+void red_LED_on(void) __attribute__((weak, alias("__red_LED_on")));
void inline __red_LED_off(void) {}
-void inline red_LED_off(void) __attribute__((weak,
alias("__red_LED_off")));
+void red_LED_off(void)__attribute__((weak, alias("__red_LED_off")));
void inline __green_LED_on(void) {}
-void inline green_LED_on(void) __attribute__((weak, alias("__green_LED_on")));
+void green_LED_on(void) __attribute__((weak, alias("__green_LED_on")));
void inline __green_LED_off(void) {}
-void inline green_LED_off(void)__attribute__((weak, alias("__green_LED_off")));
+void green_LED_off(void)__attribute__((weak, alias("__green_LED_off")));
void inline __yellow_LED_on(void) {}
-void inline yellow_LED_on(void)__attribute__((weak, alias("__yellow_LED_on")));
+void yellow_LED_on(void)__attribute__((weak, alias("__yellow_LED_on")));
void inline __yellow_LED_off(void) {}
-void inline yellow_LED_off(void)__attribute__((weak,
alias("__yellow_LED_off")));
+void yellow_LED_off(void)__attribute__((weak, alias("__yellow_LED_off")));
void inline __blue_LED_on(void) {}
-void inline blue_LED_on(void)__attribute__((weak, alias("__blue_LED_on")));
+void blue_LED_on(void)__attribute__((weak, alias("__blue_LED_on")));
void inline __blue_LED_off(void) {}
-void inline blue_LED_off(void)__attribute__((weak, alias("__blue_LED_off")));
+void blue_LED_off(void)__attribute__((weak, alias("__blue_LED_off")));
/
* Init Utilities *
--
1.6.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] OMAP2/3: I2C: Add support for second and third bus
Add support to use second and third I2C bus, too.
Bus 0 is still the default, but by calling i2c_set_bus_num(1/2) before doing
I2C accesses, code can switch to bus 1 and 2, too. Don't forget to switch
back afterwards, then.
Signed-off-by: Dirk Behme
---
Based on Hugo Vincent's patch
http://lists.denx.de/pipermail/u-boot/2009-June/055029.html
(this patch only contains the multibus support)
Compile tested with omap2_beagle and omap2420h4_config.
Boot tested with Zippy (I2C bus 1).
drivers/i2c/omap24xx_i2c.c | 170 +---
include/asm-arm/arch-omap24xx/i2c.h | 53 +++
include/asm-arm/arch-omap3/i2c.h| 50 +++---
3 files changed, 175 insertions(+), 98 deletions(-)
Index: u-boot-main/drivers/i2c/omap24xx_i2c.c
===
--- u-boot-main.orig/drivers/i2c/omap24xx_i2c.c
+++ u-boot-main/drivers/i2c/omap24xx_i2c.c
@@ -29,6 +29,15 @@ static void wait_for_bb (void);
static u16 wait_for_pin (void);
static void flush_fifo(void);
+static struct i2c *i2c_base = (struct i2c *)I2C_DEFAULT_BASE;
+
+static unsigned int bus_initialized[I2C_BUS_MAX] = {0,
+#if I2C_BUS_MAX==3
+ 0,
+#endif
+ 0};
+static unsigned int current_bus = 0;
+
void i2c_init (int speed, int slaveadd)
{
int psc, fsscll, fssclh;
@@ -95,30 +104,32 @@ void i2c_init (int speed, int slaveadd)
sclh = (unsigned int)fssclh;
}
- writew(0x2, I2C_SYSC); /* for ES2 after soft reset */
+ writew(0x2, &i2c_base->sysc); /* for ES2 after soft reset */
udelay(1000);
- writew(0x0, I2C_SYSC); /* will probably self clear but */
+ writew(0x0, &i2c_base->sysc); /* will probably self clear but */
- if (readw (I2C_CON) & I2C_CON_EN) {
- writew (0, I2C_CON);
+ if (readw (&i2c_base->con) & I2C_CON_EN) {
+ writew (0, &i2c_base->con);
udelay (5);
}
- writew(psc, I2C_PSC);
- writew(scll, I2C_SCLL);
- writew(sclh, I2C_SCLH);
+ writew(psc, &i2c_base->psc);
+ writew(scll, &i2c_base->scll);
+ writew(sclh, &i2c_base->sclh);
/* own address */
- writew (slaveadd, I2C_OA);
- writew (I2C_CON_EN, I2C_CON);
+ writew (slaveadd, &i2c_base->oa);
+ writew (I2C_CON_EN, &i2c_base->con);
/* have to enable intrrupts or OMAP i2c module doesn't work */
writew (I2C_IE_XRDY_IE | I2C_IE_RRDY_IE | I2C_IE_ARDY_IE |
- I2C_IE_NACK_IE | I2C_IE_AL_IE, I2C_IE);
+ I2C_IE_NACK_IE | I2C_IE_AL_IE, &i2c_base->ie);
udelay (1000);
flush_fifo();
- writew (0x, I2C_STAT);
- writew (0, I2C_CNT);
+ writew (0x, &i2c_base->stat);
+ writew (0, &i2c_base->cnt);
+
+ bus_initialized[current_bus] = 1;
}
static int i2c_read_byte (u8 devaddr, u8 regoffset, u8 * value)
@@ -130,19 +141,19 @@ static int i2c_read_byte (u8 devaddr, u8
wait_for_bb ();
/* one byte only */
- writew (1, I2C_CNT);
+ writew (1, &i2c_base->cnt);
/* set slave address */
- writew (devaddr, I2C_SA);
+ writew (devaddr, &i2c_base->sa);
/* no stop bit needed here */
- writew (I2C_CON_EN | I2C_CON_MST | I2C_CON_STT | I2C_CON_TRX, I2C_CON);
+ writew (I2C_CON_EN | I2C_CON_MST | I2C_CON_STT | I2C_CON_TRX,
&i2c_base->con);
status = wait_for_pin ();
if (status & I2C_STAT_XRDY) {
/* Important: have to use byte access */
- writeb (regoffset, I2C_DATA);
+ writeb (regoffset, &i2c_base->data);
udelay (2);
- if (readw (I2C_STAT) & I2C_STAT_NACK) {
+ if (readw (&i2c_base->stat) & I2C_STAT_NACK) {
i2c_error = 1;
}
} else {
@@ -151,28 +162,28 @@ static int i2c_read_byte (u8 devaddr, u8
if (!i2c_error) {
/* free bus, otherwise we can't use a combined transction */
- writew (0, I2C_CON);
- while (readw (I2C_STAT) || (readw (I2C_CON) & I2C_CON_MST)) {
+ writew (0, &i2c_base->con);
+ while (readw (&i2c_base->stat) || (readw (&i2c_base->con) &
I2C_CON_MST)) {
udelay (1);
/* Have to clear pending interrupt to clear I2C_STAT */
- writew (0x, I2C_STAT);
+ writew (0x, &i2c_base->stat);
}
wait_for_bb ();
/* set slave address */
- writew (devaddr, I2C_SA);
+ writew (devaddr, &i2c_base->sa);
/* read one byte from slave */
- writew (1, I2C_CNT);
+ writew (1, &i2c_base->cnt);
/* need stop bit here */
wr
[U-Boot] Can't see NFS packages with wireshark
Hi! I have: Board: Artila M501 board with AT91RM9200 U-Boot: 1.1.2 Kernel: 2.6.14-M5 (I know that U-Boot and Kernel are quite old, but I think for my learning purposes it is OK... Will try to update later.) My problem: I'm trying to run root-fs over nfs... I know that my nfs-server is OK, because I can mount from another linux-pc. But I'm not able to mount nfs from my target-system. And I can't see any package from my target on wireshark which is running on the nfs-server -> So it seems that my target doesn't send any packet to the server or it get lost on my net Can you see any problem with my configuration? See configuration and bootlog below: Configuration: *** baudrate=115200 ethaddr=00:13:48:00:77:b5 rootpath=/opt/arm lel=1 initrd=0x2080,8192000 ramdisk_size=15360 root=/dev/ram0 rw loader=tftp 2100 m501_64M.alf mtdparts=phys_mapped_flash:128k(loader)ro,128k(reserved)ro,1408k(linux)ro,2560(ramdisk)ro,-(userdisk) filesize=3A3 netmask=255.255.255.0 kernel=tftp 2100 M501K;erase 1004 1019;cp.b 2100 1004 $(filesize) skernel=loadb 2100;erase 1004 1019;cp.b 2100 1004 $(filesize) ramdisk=tftp 2100 M501R;erase 101a 1041;cp.b 2100 101a $(filesize) sramdisk=loadb 2100;erase 101a 1041;cp.b 2100 101a $(filesize) ipaddr=192.168.2.196 bootdelay=1 bargs=setenv bootargs mem=64M console=$(console),115200 initrd=0x2080,8192000 ramdisk_size=15360 root=/dev/ram0 rw mtdparts=phys_mapped_flash:128k(loader)ro,128k(env)ro,1408k(linux)ro,2560k(ramdisk)ro,-(userdisk) serverip=192.168.2.40 gateway=192.168.2.1 console=ttyS0 bootargs=mem=64M root=/dev/nfs rw nfsroot=192.168.2.40:/opt/arm ip=192.168.2.196:192.168.2.40:192.168.2.1:255.255.255.0:kleiner_michi::off console=ttyS0,115200 bootcmd=bootm 1004 stdin=serial stdout=serial stderr=serial *** log: *** Starting M501. Starting kernel ... Uncompressing Linux... done, booting the kernel. Linux version 2.6.14-M5 (a...@ace-yang) (gcc version 3.3.2) #837 Tue Aug 14 14:14:03 CST 2007 CPU: ARM920Tid(wb) [41129200] revision 0 (ARMv4T) Machine: Artila M501 SOM Memory policy: ECC disabled, Data cache writeback Clocks: CPU 179 MHz, master 59 MHz, main 18.432 MHz CPU0: D VIVT write-back cache CPU0: I cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets CPU0: D cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets Built 1 zonelists Kernel command line: mem=64M root=/dev/nfs rw nfsroot=192.168.2.40:/opt/arm ip=192.168.2.196:192.168.2.40:192.168.2.1:255.255.255.0:kleiner_michi::off console=ttyS0,115200 AT91: 128 gpio irqs in 4 banks PID hash table entries: 512 (order: 9, 8192 bytes) Console: colour dummy device 80x30 Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) Memory: 64MB = 64MB total Memory: 61824KB available (2389K code, 523K data, 104K init) Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok NET: Registered protocol family 16 SCSI subsystem initialized usbcore: registered new driver usbfs usbcore: registered new driver hub NetWinder Floating Point Emulator V0.97 (extended precision) JFFS2 version 2.2. (NAND) (C) 2001-2003 Red Hat, Inc. Initializing Cryptographic API Matrix500 RTC driver. Matrix500 GPIO Driver Loaded. AT91 SPI driver loaded AT91 Watchdog Timer enabled (5 seconds) ttyS0 at MMIO 0xfefff200 (irq = 1) is a AT91_SERIAL ttyS1 at MMIO 0xfefc (irq = 6) is a AT91_SERIAL ttyS2 at MMIO 0xfefc4000 (irq = 7) is a AT91_SERIAL ttyS3 at MMIO 0xfefc8000 (irq = 8) is a AT91_SERIAL ttyS4 at MMIO 0xfefcc000 (irq = 9) is a AT91_SERIAL io scheduler noop registered io scheduler anticipatory registered RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize PPP generic driver version 2.4.2 PPP BSD Compression module registered NET: Registered protocol family 24 eth0: Link now 100-FullDuplex eth0: AT91 ethernet at 0xfefbc000 int=24 100-FullDuplex (00:13:48:00:77:b5) eth0: Davicom 9161AE PHY (Copper) physmap flash device: 100 at 1000 phys_mapped_flash: Found 1 x16 devices at 0x0 in 16-bit bank Intel/Sharp Extended Query Table at 0x010A Using buffer write method cfi_cmdset_0001: Erase suspend on write enabled RedBoot partition parsing not available block2mtd: version $Revision: 1.28 $ at91rm9200-ohci at91rm9200-ohci: AT91RM9200 OHCI at91rm9200-ohci at91rm9200-ohci: new USB bus registered, assigned bus number 1 at91rm9200-ohci at91rm9200-ohci: irq 23, io mem 0x0030 usb usb1: Product: AT91RM9200 OHCI usb usb1: Manufacturer: Linux 2.6.14-M5 ohci_hcd usb usb1: SerialNumber: at91rm9200 hub 1-0:1.0: USB hub found hub 1-0:1.0: 2 ports detected usbcore: registered new driver cdc_acm drivers/usb/c
Re: [U-Boot] Can't see NFS packages with wireshark
Dear Michael Schmid, In message <4aedf129.2050...@gmx.ch> you wrote: > > I have: > Board: Artila M501 board with AT91RM9200 > U-Boot: 1.1.2 > Kernel: 2.6.14-M5 > (I know that U-Boot and Kernel are quite old, but I think for my learning > purposes it is OK... Will try to update later.) > > My problem: I'm trying to run root-fs over nfs... I know that my nfs-server > is OK, because I can mount from another linux-pc. > But I'm not able to mount nfs from my target-system. And I can't see any > package from my target on wireshark which is running on the nfs-server -> So > it seems that my target doesn't send any packet to the server or it get lost > on my net > > Can you see any problem with my configuration? See configuration and bootlog > below: Do you have support for NFS (CONFIG_NFS_FS) and root filesystem over NFS (CONFIG_ROOT_NFS) enabled in your Linux kenrel configuration? 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 is an average signature file longer than an average Perl script?? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: fix build error with gcc-4.4.2 about inline function declared weak
What is your
$(CROSS_COMPILE)gcc -v
?
Tom
walsi...@walsimou.com wrote:
> From: Abdoulaye Walsimou Gaye
>
> This patch fix build error with gcc-4.4.2 about inline function
> declared weak, see below:
> board.c:96: error: inline function 'coloured_LED_init' cannot be declared weak
> board.c:98: error: inline function 'red_LED_on' cannot be declared weak
> board.c:100: error: inline function 'red_LED_off' cannot be declared weak
> board.c:102: error: inline function 'green_LED_on' cannot be declared weak
> board.c:104: error: inline function 'green_LED_off' cannot be declared weak
> board.c:106: error: inline function 'yellow_LED_on' cannot be declared weak
> board.c:108: error: inline function 'yellow_LED_off' cannot be declared weak
> board.c:110: error: inline function 'blue_LED_on' cannot be declared weak
> board.c:112: error: inline function 'blue_LED_off' cannot be declared weak
> make[1]: *** [board.o] Error 1
>
> Signed-off-by: Abdoulaye Walsimou Gaye
> ---
> lib_arm/board.c | 18 +-
> 1 files changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/lib_arm/board.c b/lib_arm/board.c
> index 5e3d7f6..886c74c 100644
> --- a/lib_arm/board.c
> +++ b/lib_arm/board.c
> @@ -93,23 +93,23 @@ extern void rtl8019_get_enetaddr (uchar * addr);
> * May be supplied by boards if desired
> */
> void inline __coloured_LED_init (void) {}
> -void inline coloured_LED_init (void) __attribute__((weak,
> alias("__coloured_LED_init")));
> +void coloured_LED_init(void)__attribute__((weak,
> alias("__coloured_LED_init")));
> void inline __red_LED_on (void) {}
> -void inline red_LED_on (void) __attribute__((weak, alias("__red_LED_on")));
> +void red_LED_on(void) __attribute__((weak, alias("__red_LED_on")));
> void inline __red_LED_off(void) {}
> -void inline red_LED_off(void) __attribute__((weak,
> alias("__red_LED_off")));
> +void red_LED_off(void)__attribute__((weak, alias("__red_LED_off")));
> void inline __green_LED_on(void) {}
> -void inline green_LED_on(void) __attribute__((weak,
> alias("__green_LED_on")));
> +void green_LED_on(void) __attribute__((weak, alias("__green_LED_on")));
> void inline __green_LED_off(void) {}
> -void inline green_LED_off(void)__attribute__((weak,
> alias("__green_LED_off")));
> +void green_LED_off(void)__attribute__((weak, alias("__green_LED_off")));
> void inline __yellow_LED_on(void) {}
> -void inline yellow_LED_on(void)__attribute__((weak,
> alias("__yellow_LED_on")));
> +void yellow_LED_on(void)__attribute__((weak, alias("__yellow_LED_on")));
> void inline __yellow_LED_off(void) {}
> -void inline yellow_LED_off(void)__attribute__((weak,
> alias("__yellow_LED_off")));
> +void yellow_LED_off(void)__attribute__((weak, alias("__yellow_LED_off")));
> void inline __blue_LED_on(void) {}
> -void inline blue_LED_on(void)__attribute__((weak, alias("__blue_LED_on")));
> +void blue_LED_on(void)__attribute__((weak, alias("__blue_LED_on")));
> void inline __blue_LED_off(void) {}
> -void inline blue_LED_off(void)__attribute__((weak, alias("__blue_LED_off")));
> +void blue_LED_off(void)__attribute__((weak, alias("__blue_LED_off")));
>
> /
> * Init Utilities*
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: fix build error with gcc-4.4.2 about inline function declared weak
Dear Tom, In message <4aedfc0d.8020...@windriver.com> you wrote: > What is your > $(CROSS_COMPILE)gcc -v > ? Tom, please note this issue is old, and in any case a patch,if checked in, should be properly attributed. I think the first to bring this up was Ron Lee; please see the whole thread here: http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/65397 > walsi...@walsimou.com wrote: > > From: Abdoulaye Walsimou Gaye > > > > This patch fix build error with gcc-4.4.2 about inline function > > declared weak, see below: Looks exactly the same as Ron's patch to me... 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 trouble with our times is that the future is not what it used to be. - Paul Valery ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: fix build error with gcc-4.4.2 about inline function declared weak
Tom wrote: > What is your > $(CROSS_COMPILE)gcc -v > ? > Tom > This is a home made toolchain. With same options with gcc-4.3.4, gcc-4.4.1, no build error. armel-linux-gcc -v Using built-in specs. Target: armel-unknown-linux-gnueabi Configured with: /usr/src/walsimou/embtoolkit-0.1.0-rc5/build/tools_build-armel-linux-arm920t/gcc-4.4.2/configure --prefix=/usr/src/walsimou/embtoolkit-0.1.0-rc5/tools-armel-linux-arm920t --with-sysroot=/usr/src/walsimou/embtoolkit-0.1.0-rc5/sysroot-armel-linux-arm920t --target=armel-unknown-linux-gnueabi --with-cpu=arm920t --with-float=soft --disable-multilib --host=x86_64-unknown-linux-gnu --build=x86_64-unknown-linux-gnu --enable-__cxa_atexit --disable-libssp --disable-libgomp --disable-libmudflap --disable-nls --enable-threads --enable-shared --with-gmp=/usr/src/walsimou/embtoolkit-0.1.0-rc5/host-tools-arm920t/usr/local/gmp-host --with-mpfr=/usr/src/walsimou/embtoolkit-0.1.0-rc5/host-tools-arm920t/usr/local/mpfr-host --enable-languages=c Thread model: posix gcc version 4.4.2 (GCC) Thanks ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC 1/5] CAN interface library
Mike Frysinger wrote:
> On Sunday 01 November 2009 11:16:59 Wolfgang Grandegger wrote:
>> Mike Frysinger wrote:
>>> On Sunday 01 November 2009 06:33:33 Wolfgang Grandegger wrote:
--- /dev/null
+++ b/drivers/can/can.c
+static char *baudrates[] = { "125K", "250K", "500K" };
>>> so we're restricting ourselves to these three speeds ? i have passing
>>> familiarity with CAN, but i didnt think the protocol was restricted to
>>> specific speeds.
>> Well, this is an RFC and as I wrote in the introduction some features
>> need to be added or extended, especially for CAN device configuration.
>> My idea is to have a more complete default bit-timing table, which board
>> specific code may overwrite using, for example:
>>
>>sja1000_register(&my_sja1000, &my_config_opts);
>>
>> This would also allow to set the CAN clock, cdr and ocr registers.
>
> this makes sense if the device supports a limited number of baud rates. but
> what if the baud rate is arbitrary (between two limits) ?
Board specific code can define what ever table it likes, including
non-standard bit-rate and bit-timings. Nevertheless, for most CAN
controllers the default bit-timing parameters are just fine.
+int can_register (struct can_dev* can_dev)
>>> no space before the paren, and the * is cuddled on the wrong side of the
>>> space. seems like a lot of this code suffers from these two issues.
>> U-Boot coding style requires a space after the function name and before
>> "(". But the "*" is misplaced, of course.
>
> it's (thankfully) been changing to Linux kernel style
I really appreciate that.
+struct can_dev *can_init (int dev_num, int ibaud)
>>> wonder if we should have a generic device list code base since this looks
>>> similar to a lot of other u-boot device lists ...
>> Do we already have a generic interface?
>
> i dont think so
Nor do I.
Wolfgang.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH-ARM 1/3] Add support for the s3c2440 cpu excluding nand driver
kevin.morf...@fearnside-systems.co.uk wrote: > This patch adds support for the s3c2440 cpu, excluding the nand driver. > > Tested on an Embest SBC2440-II Board with local u-boot patches as I don't have > any s3c2400 or s3c2410 boards but need this patch applying before I can submit > patches for the SBC2440-II Board. Also, ran MAKEALL for all ARM9 targets and > no > new warnings or errors were found. > > Note that checkpatch.pl shows one error: Thank you for using checkpatch. > > ERROR: Invalid UTF-8, patch and commit message should be encoded in UTF-8 > #656: FILE: include/s3c2440.h:3: > + * David M�ller ELSOFT AG Switzerland. d.muel...@elsoft.ch >^ > As David's name correctly contains a non-UTF-8 character I've ignored this > error. > > Signed-off-by: Kevin Morfitt > --- > common/serial.c |4 +- > cpu/arm920t/s3c24x0/Makefile |6 +- > cpu/arm920t/s3c24x0/arch_pre_lowlevel_init.S | 81 + Why not just lowlevel_init.S ? It looks like this is a common lowlevel_init but this looks like a mistake since the other s3c34x0 boards have not used it up to to this point. Since it looks like this option is being enabled in the other boards, this change must be broken out at its own patch. > cpu/arm920t/s3c24x0/speed.c | 41 +-- > cpu/arm920t/s3c24x0/timer.c | 19 +--- > cpu/arm920t/s3c24x0/usb.c| 17 +-- > cpu/arm920t/s3c24x0/usb_ohci.c | 11 +-- > cpu/arm920t/start.S | 39 +-- > drivers/i2c/s3c24x0_i2c.c| 18 ++-- > drivers/mtd/nand/s3c2410_nand.c |2 +- > drivers/rtc/s3c24x0_rtc.c|7 +- > drivers/serial/serial_s3c24x0.c |6 +- > drivers/usb/host/ohci-hcd.c |3 +- > include/common.h |5 +- > include/configs/VCMA9.h |4 +- > include/configs/sbc2410x.h |4 +- > include/configs/smdk2400.h |4 +- > include/configs/smdk2410.h |4 +- > include/configs/trab.h |4 +- This is typical of what you are doing with the config files. > +#define CONFIG_S3C24X0 1 /* in a SAMSUNG S3C24x0-type > SoC */ > +#define CONFIG_S3C2410 1 /* specifically a SAMSUNG > S3C2410 SoC */ It is good that you are trying to generalize the boards, but this separate change and must be split. This new patch should come first. > include/s3c2410.h| 25 > include/s3c2440.h| 163 > ++ > include/s3c24x0.h| 94 ++- > include/s3c24x0_cpu.h| 29 + These 4 files belong in include/asm-arch/arch-s3c24x0 or where Minkyu thinks is appropriate. On your include file s3c2440.h For your #defines, the whitespace between the identifier and the value must be tabs. You have spaces. The static inline functions need space beween one function definition and the next. They also need to use tabs > 23 files changed, 471 insertions(+), 119 deletions(-) > create mode 100644 cpu/arm920t/s3c24x0/arch_pre_lowlevel_init.S > create mode 100644 include/s3c2440.h > create mode 100644 include/s3c24x0_cpu.h > Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH-ARM 2/3] Add sc32440 support to the s3c2410 nand driver
kevin.morf...@fearnside-systems.co.uk wrote: > This patch adds support for the s3c2440 cpu to the nand driver. It does > this by replacing the existing driver with that from linux 2.6.31.5, > modified to make it work in the u-boot mtd nand architecture. Note that > the linux s3c2410 nand driver supports s3c2410 and s3c2440, though I haven't > been able to test this on an s3c2410 board, only an s3c2440 board. > > Tested on an Embest SBC2440-II Board with local u-boot patches as I don't have > any s3c2400 or s3c2410 boards but need this patch applying before I can submit > patches for the SBC2440-II Board. Also, ran MAKEALL for all ARM9 targets and > no > new warnings or errors were found. > My opinion is that this change should be slit into the driver update and s3c2440 changes. Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: fix build error with gcc-4.4.2 about inline function declared weak
Wolfgang Denk wrote: > Dear Tom, > > In message <4aedfc0d.8020...@windriver.com> you wrote: >> What is your >> $(CROSS_COMPILE)gcc -v >> ? > > Tom, please note this issue is old, and in any case a patch,if checked > in, should be properly attributed. I think the first to bring this up > was Ron Lee; please see the whole thread here: > http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/65397 > >> walsi...@walsimou.com wrote: >>> From: Abdoulaye Walsimou Gaye >>> >>> This patch fix build error with gcc-4.4.2 about inline function >>> declared weak, see below: > > Looks exactly the same as Ron's patch to me... > Deja vu.. Let try to fix it this time. The hold up issue is non inline, adds some wasted bytes. Is the linker smart enough to garbage collect them away ? Tom > Best regards, > > Wolfgang Denk > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH-ARM 3/3] Add Support for the SBC2440-II Board
kevin.morf...@fearnside-systems.co.uk wrote: > This patch adds support for the Embest SBC2440-II Board. > > Tested on an Embest SBC2440-II Board with local u-boot patches as I don't have > any s3c2400 or s3c2410 boards but need this patch applying before I can submit > patches for the SBC2440-II Board. Also, ran MAKEALL for all ARM9 targets and > no > new warnings or errors were found. Please change this commit to describe the new board in general terms. Add a link to the product if it is long lived. The testing results are more appropriate for the intro patch. 0 of n that git send-email creates. > > Signed-off-by: Kevin Morfitt > --- > MAINTAINERS|4 + > MAKEALL|1 + > 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 | 122 +++ > cpu/arm920t/s3c24x0/timer.c|1 + > include/configs/sbc2440ii.h| 254 > > 9 files changed, 684 insertions(+), 0 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 include/configs/sbc2440ii.h > > diff --git a/MAINTAINERS b/MAINTAINERS > index d70a9d2..65f8dfe 100644 > --- a/MAINTAINERS > new file mode 100644 > index 000..95f49f8 > --- /dev/null > +++ b/board/embest/sbc2440ii/lowlevel_init.S > @@ -0,0 +1,219 @@ > +/* > + * Memory Setup stuff - taken from blob memsetup.S > + * > + * Copyright (C) 1999 2000 2001 Erik Mouw (j.a.k.m...@its.tudelft.nl) and > + * Jan-Derk Bakker (j.d.bak...@its.tudelft.nl) > + * > + * Modified for the Samsung SMDK2410 by > + * (C) Copyright 2002 > + * David Mueller, ELSOFT AG, > + * > + * Modified for the friendly-arm SBC-2410X by > + * (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 > + > +/* > + * Taken from linux/arch/arm/boot/compressed/head-s3c2410.S > + * > + * Copyright (C) 2002 Samsung Electronics SW.LEE > + */ This copyright should go with the others > + > +#define BWSCON 0x4800 > + > +#define DW8 (0x0) > +#define DW16 (0x1) > +#define DW32 (0x2) > +#define WAIT (0x1 << 2) > +#define UBLB (0x1 << 3) > + > diff --git a/board/embest/sbc2440ii/sbc2440ii.c > b/board/embest/sbc2440ii/sbc2440ii.c > new file mode 100644 > index 000..7c793e9 > --- /dev/null > +++ b/board/embest/sbc2440ii/sbc2440ii.c > @@ -0,0 +1,122 @@ > +/* > + * (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,
[U-Boot] Net driver questions
Hello, Please forgive me if answers to my questions are obvious, I'm new to U-Boot. I'm trying to port the Ethernet driver for Intel IXP4xx CPU from Linux (I know there is Intel's code already ported). I've read the doc/README.drivers.eth. I came across some problems: - dev->halt() seems to be called before the first call to dev->init() (i.e., before the hardware is initialized). Is it on purpose? - dev->recv() seems to be called recursively, for example while doing "dhcp" or "bootp" (ping is ok). dev->recv() in my driver calls NetReceive(), which in turn (without returning to the caller, i.e., dev->recv(), first) reinitializes the driver on error (calls dev->halt() and dev->init()). This makes a lot of mess in the driver, should it stay this way? Perhaps we should queue the received packets and process them on return from dev->recv()? Or maybe return all those packets together? - dev->recv() is provided with RX packet buffers. IXP4xx can only receive to already allocated memory so the driver has to provide it's own buffers prior to dev->recv(). I assume it's common situation with all hardware recent enough. Does the driver have to copy data to NetRxPackets[], or is it ok to simply call NetReceive using driver's buffers? -- Krzysztof Halasa ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sheevaplug: correct SDRAM address control register value
Prafulla Wadaskar wrote: > Hi Tom > > Please pull > > The following changes since commit 21e0b054c4285f7a497ac4510acf0ae90a28eae0: > Tom Rix (1): > ARM Update mach-types.h > > are available in the git repository at: > > u-boot-marvell.git on next branch ..BRANCH.NOT.VERIFIED.. > > Mark Asselstine (1): > sheevaplug: correct SDRAM address control register > > board/Marvell/sheevaplug/kwbimage.cfg | 10 +- > 1 files changed, 5 insertions(+), 5 deletions(- > > Regards.. > Prafulla . . > I have pushed this to arm/next. Thanks. Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] S3C6400/SMDK6400: fix stack_setup in start.S
Dear Seunghyeon Rhee 2009/10/31 "Seunghyeon Rhee (이승현)" : > stack_setup is modified to initialize the stack on the correct address in > DRAM accroding to the typical memory configuration described in > README and the related CONFIG_* macro definitions. This makes macro > CONFIG_MEMORY_UPPER_CODE no longer necessry. This was introduced > and used only by this board for some unclear reason. The definition of > this macro is removed because it's not referenced elsewhere. > > Signed-off-by: Seunghyeon Rhee > --- > cpu/arm1176/start.S | 7 +-- > include/configs/smdk6400.h | 2 -- > 2 files changed, 1 insertions(+), 8 deletions(-) > > diff --git a/cpu/arm1176/start.S b/cpu/arm1176/start.S > index cb891df..1ecb3b9 100644 > --- a/cpu/arm1176/start.S > +++ b/cpu/arm1176/start.S > @@ -241,16 +241,11 @@ mmu_enable: > skip_hw_init: > /* Set up the stack */ > stack_setup: > -#ifdef CONFIG_MEMORY_UPPER_CODE > - ldr sp, =(CONFIG_SYS_UBOOT_BASE + CONFIG_SYS_UBOOT_SIZE - 0xc) > -#else > - ldr r0, _TEXT_BASE /* upper 128 KiB: relocated uboot */ > + ldr r0, =CONFIG_SYS_UBOOT_BASE /* base of copy in DRAM */ this change is unnecessary, TEXT_BASE and CONFIG_SYS_UBOOT_BASE must be same. btw, is there need CONFIG_SYS_UBOOT_BASE define? > sub r0, r0, #CONFIG_SYS_MALLOC_LEN /* malloc > area */ > sub r0, r0, #CONFIG_SYS_GBL_DATA_SIZE /* > bdinfo */ > sub sp, r0, #12 /* leave 3 words for abort-stack */ > > -#endif > - > clear_bss: > ldr r0, _bss_start /* find start of bss segment */ > ldr r1, _bss_end /* stop here */ > diff --git a/include/configs/smdk6400.h b/include/configs/smdk6400.h > index f6e1221..f644cd2 100644 > --- a/include/configs/smdk6400.h > +++ b/include/configs/smdk6400.h > @@ -49,8 +49,6 @@ > #define CONFIG_ENABLE_MMU > #endif > > -#define CONFIG_MEMORY_UPPER_CODE > - > #define CONFIG_SETUP_MEMORY_TAGS > #define CONFIG_CMDLINE_TAG > #define CONFIG_INITRD_TAG > -- > 1.6.2.5 > > > -- > Seunghyeon Rhee, Ph.D. / Director > LPM Technology Inc. > T +82-70-8255-6007 F +82-2-6442-6462 > M +82-10-2790-0657 > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > Thanks for patch :) Minkyu Kang -- from. prom. www.promsoft.net ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] about nand_read_byte() interface
Thank you, Scott :)
> Date: Fri, 30 Oct 2009 11:42:19 -0500
> From: scottw...@freescale.com
> To: leon...@msn.com
> CC: u-boot@lists.denx.de
> Subject: Re: [U-Boot] about nand_read_byte() interface
>
> On Fri, Oct 30, 2009 at 01:20:58PM +0800, HeLei wrote:
> >
> > Hi, all
>
> Hi, please wrap your lines at 75 or so characters -- and definitely don't
> paste code as all one line.
Sorry, I change to another email client, I hope it will be okay this time.
> > I'm a little confused on NAND read operation.
> > According to NAND character, NAND flash is read page by page, which mean's
> > once you read, at least you should read data with page size (such as
> > 512Bytes)
>
> Yes, unless you're reading from the out-of-band area.
So, this means we have to call nand_read() to get the whole page, even if we
just need a single byte in the page. And the call chain is as following:
mtd->nand => nand_read => nand_do_read_ops =>nand_read_page_raw => ...
Do I get it ?
> > But the nand_read_byte() is implemented as following: static u_char
> > nand_read_byte(struct mtd_info *mtd) { struct nand_chip *this = mtd->priv;
> > return readb(this->IO_ADDR_R); }
> > it seems only one byte is read out.
>
> It's reading one byte out of a buffer that was previously filled with some
> operation. It is used for reading status bytes and OOB bad block markers.
Yes, interface nand_read_byte() is often used to read out status byte or
OOB byte, after I review the code.
> -Scott
_
全新 Windows 7：寻找最适合您的 PC。了解详情。
http://www.microsoft.com/china/windows/buy/ ___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] S3C6400/SMDK6400: fix stack_setup in start.S
Dear Minkyu Kang, 2009/11/2 Minkyu Kang : > Dear Seunghyeon Rhee > > 2009/10/31 "Seunghyeon Rhee (이승현)" : >> stack_setup is modified to initialize the stack on the correct address in >> DRAM accroding to the typical memory configuration described in >> README and the related CONFIG_* macro definitions. This makes macro >> CONFIG_MEMORY_UPPER_CODE no longer necessry. This was introduced >> and used only by this board for some unclear reason. The definition of >> this macro is removed because it's not referenced elsewhere. >> >> Signed-off-by: Seunghyeon Rhee >> --- >> cpu/arm1176/start.S|7 +-- >> include/configs/smdk6400.h |2 -- >> 2 files changed, 1 insertions(+), 8 deletions(-) >> >> diff --git a/cpu/arm1176/start.S b/cpu/arm1176/start.S >> index cb891df..1ecb3b9 100644 >> --- a/cpu/arm1176/start.S >> +++ b/cpu/arm1176/start.S >> @@ -241,16 +241,11 @@ mmu_enable: >> skip_hw_init: >> /* Set up the stack*/ >> stack_setup: >> -#ifdef CONFIG_MEMORY_UPPER_CODE >> -ldrsp, =(CONFIG_SYS_UBOOT_BASE + CONFIG_SYS_UBOOT_SIZE - 0xc) >> -#else >> -ldrr0, _TEXT_BASE/* upper 128 KiB: relocated uboot */ >> +ldrr0, =CONFIG_SYS_UBOOT_BASE/* base of copy in DRAM*/ > > this change is unnecessary, TEXT_BASE and CONFIG_SYS_UBOOT_BASE must be same. That's true for the body of U-Boot but not for SPL, where TEXT_BASE is defined to be '0'. Please refer to board/samsung/smdk6400/config.mk. On the other hand, CONFIG_SYS_UBOOT_BASE is always dependent on DRAM's base. In SPL, the base of the code should be '0' (the steppingstone memory) and then the stack is located below '0' - not a valid area. If SPL itself requires no stack, it should be no problem. But start.S calls nand_boot function right after the stack is badly set up in the air. My test results are like the following: with CONFIG_MEMORY_UPPER_CODE defined : OK with CONFIG_MEMORY_UPPER_CODE undefined : - SPL bypassed (U-Boot downloaded to DRAM directly by USB monitor program) : OK - through SPL : Not OK (seems to fail for SPL downloading the code to DRAM) I think CONFIG_MEMORY_UPPER_CODE was tested for the case it's defined but not enough for the case it's not defined. Would you check it again? > btw, is there need CONFIG_SYS_UBOOT_BASE define? > If you are not sure, why did you use CONFIG_SYS_UBOOT_BASE for the case CONFIG_MEMORY_UPPER_CODE is defined while you use TEXT_BASE otherwise? I think the unnecessary macro definition here is not CONFIG_..._BASE but CONFIG_..._CODE. TEXT_BASE and CONFIG_..._BASE have their own meanings and so both are necessary. Best regards, Seunghyeon >> subr0, r0, #CONFIG_SYS_MALLOC_LEN/* malloc >> area */ >> subr0, r0, #CONFIG_SYS_GBL_DATA_SIZE /* >> bdinfo*/ >> subsp, r0, #12/* leave 3 words for abort-stack*/ >> >> -#endif >> - >> clear_bss: >> ldrr0, _bss_start/* find start of bss segment*/ >> ldrr1, _bss_end/* stop here*/ >> diff --git a/include/configs/smdk6400.h b/include/configs/smdk6400.h >> index f6e1221..f644cd2 100644 >> --- a/include/configs/smdk6400.h >> +++ b/include/configs/smdk6400.h >> @@ -49,8 +49,6 @@ >> #define CONFIG_ENABLE_MMU >> #endif >> >> -#define CONFIG_MEMORY_UPPER_CODE >> - >> #define CONFIG_SETUP_MEMORY_TAGS >> #define CONFIG_CMDLINE_TAG >> #define CONFIG_INITRD_TAG >> -- >> 1.6.2.5 >> >> >> -- >> Seunghyeon Rhee, Ph.D. / Director >> LPM Technology Inc. >> T +82-70-8255-6007 F +82-2-6442-6462 >> M +82-10-2790-0657 >> ___ >> U-Boot mailing list >> U-Boot@lists.denx.de >> http://lists.denx.de/mailman/listinfo/u-boot >> > > Thanks for patch :) > Minkyu Kang > -- > from. prom. > www.promsoft.net > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > -- Seunghyeon Rhee, Ph.D. / Director LPM Technology Inc. T +82-70-8255-6007 F +82-2-6442-6462 M +82-10-2790-0657 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Net driver questions
On Sunday 01 November 2009 18:07:43 Krzysztof Halasa wrote: > I'm trying to port the Ethernet driver for Intel IXP4xx CPU from Linux > (I know there is Intel's code already ported). I've read the > doc/README.drivers.eth. I came across some problems: > - dev->halt() seems to be called before the first call to > dev->init() (i.e., before the hardware is initialized). Is it on > purpose? it's on purpose because it makes the code simpler -- no need to maintain state. drivers have to be able to handle halt() irregardless of init(). i dont see this being a problem for anyone. > - dev->recv() seems to be called recursively, for example while doing > "dhcp" or "bootp" (ping is ok). dev->recv() in my driver calls > NetReceive(), which in turn (without returning to the caller, i.e., > dev->recv(), first) reinitializes the driver on error (calls > dev->halt() and dev->init()). This makes a lot of mess in the driver, > should it stay this way? Perhaps we should queue the received packets > and process them on return from dev->recv()? Or maybe return all those > packets together? where exactly do you see that call path ? i dont see it anywhere ... NetReceive() may call eth_send(), but that only expands into dev->send() > - dev->recv() is provided with RX packet buffers. IXP4xx can only > receive to already allocated memory so the driver has to provide it's > own buffers prior to dev->recv(). I assume it's common situation with > all hardware recent enough. Does the driver have to copy data to > NetRxPackets[], or is it ok to simply call NetReceive using driver's > buffers? the NetRxPackets[] are set up for you by default and are merely a convenience. you can use them or not, it doesnt really matter. after all, your driver is what calls NetReceive() and the first argument there is the buffer that you're receiving. none of the internal network code relies on these pointers. i'll send out a patch to cover some of the finer details in the drivers doc. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] clarify eth driver halt/recv steps
The dev->halt() func can be called at any time, and the dev->recv() func
does not need to use NetRxPackets[] when calling NetReceive().
Signed-off-by: Mike Frysinger
---
doc/README.drivers.eth | 13 -
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/doc/README.drivers.eth b/doc/README.drivers.eth
index e73e462..d0c3571 100644
--- a/doc/README.drivers.eth
+++ b/doc/README.drivers.eth
@@ -122,10 +122,12 @@ function can be called multiple times in a row.
The recv function should process packets as long as the hardware has them
readily available before returning. i.e. you should drain the hardware fifo.
-The common code sets up packet buffers for you already (NetRxPackets), so there
-is no need to allocate your own. For each packet you receive, you should call
-the NetReceive() function on it with the packet length. So the pseudo code
-here would look something like:
+For each packet you receive, you should call the NetReceive() function on it
+along with the packet length. The common code sets up packet buffers for you
+already in the .bss (NetRxPackets), so there should be no need to allocate your
+own. This doesn't mean you must use the NetRxPackets array however; you're
+free to call the NetReceive() function with any buffer you wish. So the pseudo
+code here would look something like:
int ape_recv(struct eth_device *dev)
{
int length, i = 0;
@@ -145,7 +147,8 @@ int ape_recv(struct eth_device *dev)
}
The halt function should turn off / disable the hardware and place it back in
-its reset state.
+its reset state. It can be called at any time (before any call to the related
+init function), so make sure it can handle this sort of thing.
So the call graph at this stage would look something like:
some net operation (ping / tftp / whatever...)
--
1.6.5.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH-ARM 1/3] Add support for the s3c2440 cpu excluding nand driver
Dear kevin.morfitt and Tom 2009/11/2 Tom : > kevin.morf...@fearnside-systems.co.uk wrote: >> This patch adds support for the s3c2440 cpu, excluding the nand driver. >> >> Tested on an Embest SBC2440-II Board with local u-boot patches as I don't >> have >> any s3c2400 or s3c2410 boards but need this patch applying before I can >> submit >> patches for the SBC2440-II Board. Also, ran MAKEALL for all ARM9 targets and >> no >> new warnings or errors were found. >> >> Note that checkpatch.pl shows one error: > > Thank you for using checkpatch. > >> >> ERROR: Invalid UTF-8, patch and commit message should be encoded in UTF-8 >> #656: FILE: include/s3c2440.h:3: >> + * David M�ller ELSOFT AG Switzerland. d.muel...@elsoft.ch >> ^ >> As David's name correctly contains a non-UTF-8 character I've ignored this >> error. >> >> Signed-off-by: Kevin Morfitt >> --- >> common/serial.c | 4 +- >> cpu/arm920t/s3c24x0/Makefile | 6 +- >> cpu/arm920t/s3c24x0/arch_pre_lowlevel_init.S | 81 + > > Why not just lowlevel_init.S ? > It looks like this is a common lowlevel_init but this looks like > a mistake since the other s3c34x0 boards have not used it up to to this > point. Since it looks like this option is being enabled in the > other boards, this change must be broken out at its own patch. > > >> cpu/arm920t/s3c24x0/speed.c | 41 +-- >> cpu/arm920t/s3c24x0/timer.c | 19 +--- >> cpu/arm920t/s3c24x0/usb.c | 17 +-- >> cpu/arm920t/s3c24x0/usb_ohci.c | 11 +-- >> cpu/arm920t/start.S | 39 +-- >> drivers/i2c/s3c24x0_i2c.c | 18 ++-- >> drivers/mtd/nand/s3c2410_nand.c | 2 +- >> drivers/rtc/s3c24x0_rtc.c | 7 +- >> drivers/serial/serial_s3c24x0.c | 6 +- >> drivers/usb/host/ohci-hcd.c | 3 +- >> include/common.h | 5 +- > >> include/configs/VCMA9.h | 4 +- >> include/configs/sbc2410x.h | 4 +- >> include/configs/smdk2400.h | 4 +- >> include/configs/smdk2410.h | 4 +- >> include/configs/trab.h | 4 +- > > This is typical of what you are doing with the config files. >> +#define CONFIG_S3C24X0 1 /* in a SAMSUNG S3C24x0-type >> SoC */ >> +#define CONFIG_S3C2410 1 /* specifically a SAMSUNG >> S3C2410 SoC */ > It is good that you are trying to generalize the boards, but > this separate change and must be split. This new patch should come first. > >> include/s3c2410.h | 25 >> include/s3c2440.h | 163 >> ++ >> include/s3c24x0.h | 94 ++- >> include/s3c24x0_cpu.h | 29 + > > These 4 files belong in include/asm-arch/arch-s3c24x0 or > where Minkyu thinks is appropriate. yes right, I think these file must be move to include/asm-arch/arch-s3c24x0 kevin, could you please make the patch about this also? It seems to be another patch. If you busy, I'll do it :) > > On your include file s3c2440.h > > For your #defines, the whitespace between the identifier and the value > must be tabs. You have spaces. > > The static inline functions need space beween one function definition > and the next. They also need to use tabs > >> 23 files changed, 471 insertions(+), 119 deletions(-) >> create mode 100644 cpu/arm920t/s3c24x0/arch_pre_lowlevel_init.S >> create mode 100644 include/s3c2440.h >> create mode 100644 include/s3c24x0_cpu.h >> > > Tom > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > Thanks Minkyu Kang -- from. prom. www.promsoft.net ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] NET: Fix MAC addr handling for smc911x
This patch turns off MAC address mismatch warning when
optional eeprom programmed with MAC address is not available.
In that case, smc911x's MAC address register has its default
value ff:ff:ff:ff:ff:ff and it's not a valid address. This
makes eth_initialize() show the warning which has no
meaningful information while environment variable ethaddr
overrides the address read from the register. If there's no
eeprom and the value of MAC address register is not valid
after initialization, dev->enetaddr had better not be updated
and maintain its initial value 00:00:00:00:00:00, which I
think is what eth_initialize() expects. This is not a bug fix.
Even without this patch, the driver works fine. It's just for
enhancing the way of displaying messages.
Signed-off-by: Seunghyeon Rhee
---
drivers/net/smc911x.c | 15 +--
1 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/net/smc911x.c b/drivers/net/smc911x.c
index c50758e..3244850 100644
--- a/drivers/net/smc911x.c
+++ b/drivers/net/smc911x.c
@@ -257,12 +257,15 @@ int smc911x_initialize(u8 dev_num, int base_addr)
addrh = smc911x_get_mac_csr(dev, ADDRH);
addrl = smc911x_get_mac_csr(dev, ADDRL);
- dev->enetaddr[0] = addrl;
- dev->enetaddr[1] = addrl >> 8;
- dev->enetaddr[2] = addrl >> 16;
- dev->enetaddr[3] = addrl >> 24;
- dev->enetaddr[4] = addrh;
- dev->enetaddr[5] = addrh >> 8;
+ if (!(addrl == 0x && addrh == 0x)) {
+ /* address is obtained from optional eeprom */
+ dev->enetaddr[0] = addrl;
+ dev->enetaddr[1] = addrl >> 8;
+ dev->enetaddr[2] = addrl >> 16;
+ dev->enetaddr[3] = addrl >> 24;
+ dev->enetaddr[4] = addrh;
+ dev->enetaddr[5] = addrh >> 8;
+ }
dev->init = smc911x_init;
dev->halt = smc911x_halt;
--
1.6.2.5
--
Seunghyeon Rhee, Ph.D. / Director
LPM Technology Inc.
T +82-70-8255-6007 F +82-2-6442-6462
M +82-10-2790-0657
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
