[U-Boot] [PATCH v6] mpq101: initial support for Mercury Computer Systems MPQ101 board
Mpq101 is a RapidIO development board in AMC form factor, featuring MPC8548 processor, 512MB of hardwired DDR2 RAM, 128MB of hardwired NAND flash memory, real time clock and additional serial EEPROM on i2c bus (enabled). USB controller is available, but not presently enabled. Additional board information is available at: http://www.mc.com/products/boards/ensemble_mpq101_rapidio_powerquicc_iii.aspx Environment is configured to precede the actual u-boot image so that it's located at the beginning of flash erase block (made necessary by the recent changes to the embedded environment handling). This is achieved by means of custom ld script. Signed-off-by: Alex Dubov oa...@yahoo.com --- Changes for v6: - Remove 1s from feature defines and fix a SRIO ifdef in tlb.c Changes for v5: - Use new common SRIO configuration definitions. - Replace initdram() with platform required fixed_sdram(). - Don't use get_ram_size() in fixed_sdram() as TLBs are set after it exits by common platform code. Changes for v4: - Replace config.mk supplied linker flags with custom linker script. - Fix checkpatch errors. Changes for v3: - Use io accessor functions for all mmio accesses. - Add configuration options for RTC and EEPROM on I2C buses. Changes for v2: - Remove some stale configuration code from board initialization functions. MAINTAINERS |3 + board/mercury/mpq101/Makefile | 53 ++ board/mercury/mpq101/law.c | 52 + board/mercury/mpq101/mpq101.c | 129 + board/mercury/mpq101/tlb.c | 82 board/mercury/mpq101/u-boot.lds | 132 + boards.cfg |1 + include/configs/mpq101.h| 392 +++ 8 files changed, 844 insertions(+), 0 deletions(-) create mode 100644 board/mercury/mpq101/Makefile create mode 100644 board/mercury/mpq101/law.c create mode 100644 board/mercury/mpq101/mpq101.c create mode 100644 board/mercury/mpq101/tlb.c create mode 100644 board/mercury/mpq101/u-boot.lds create mode 100644 include/configs/mpq101.h diff --git a/MAINTAINERS b/MAINTAINERS index a799037..d0fc7dc 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -138,6 +138,9 @@ Jon Diekema jon.diek...@smiths-aerospace.com sbc8260 MPC8260 +Alex Dubov oa...@yahoo.com + mpq101 MPC8548 + Dirk Eibach eib...@gdsys.de devconcenterPPC460EX diff --git a/board/mercury/mpq101/Makefile b/board/mercury/mpq101/Makefile new file mode 100644 index 000..58bc1b3 --- /dev/null +++ b/board/mercury/mpq101/Makefile @@ -0,0 +1,53 @@ +# +# Copyright 2007 Freescale Semiconductor, Inc. +# (C) Copyright 2001-2006 +# 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)lib$(BOARD).o + +COBJS-y+= $(BOARD).o +COBJS-y+= law.o +COBJS-y+= tlb.o + +SRCS := $(SOBJS:.o=.S) $(COBJS-y:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS-y)) +SOBJS := $(addprefix $(obj),$(SOBJS)) + +$(LIB):$(obj).depend $(OBJS) $(SOBJS) + $(call cmd_link_o_target, $(OBJS)) + +clean: + rm -f $(OBJS) $(SOBJS) + +distclean: clean + rm -f $(LIB) core *.bak .depend + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/board/mercury/mpq101/law.c b/board/mercury/mpq101/law.c new file mode 100644 index 000..0e23a6a --- /dev/null +++ b/board/mercury/mpq101/law.c @@ -0,0 +1,52 @@ +/* + * Copyright 2008 Freescale Semiconductor, Inc. + * + * (C) Copyright 2000 + * 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
Re: [U-Boot] [PATCH] ppc4xx: Support dual link OSD
Dear Dirk Eibach,
Dear Wolfgang,
...
#define BASE_WIDTH 32
@@ -38,12 +44,18 @@
enum {
REG_CONTROL = 0x0010,
REG_MPC3W_CONTROL = 0x001a,
+ REG_EXT_INTERRUPT = 0x001c,
+ REG_EXT_INTERRUPT_ENABLE = 0x001e,
+ REG_IIC_WRITE_MAILBOX = 0x0030,
+ REG_IIC_WRITE_MAILBOX_EXT = 0x0032,
+ REG_IIC_READ_MAILBOX = 0x0034,
+ REG_IIC_READ_MAILBOX_EXT = 0x0036,
REG_VIDEOCONTROL = 0x0042,
- REG_OSDVERSION = 0x0100,
- REG_OSDFEATURES = 0x0102,
- REG_OSDCONTROL = 0x0104,
- REG_XY_SIZE = 0x0106,
- REG_VIDEOMEM = 0x0800,
+ REG_OSDVERSION = CONFIG_SYS_FPGA_OSD_BASE + 0x,
+ REG_OSDFEATURES = CONFIG_SYS_FPGA_OSD_BASE + 0x0002,
+ REG_OSDCONTROL = CONFIG_SYS_FPGA_OSD_BASE + 0x0004,
+ REG_XY_SIZE = CONFIG_SYS_FPGA_OSD_BASE + 0x0006,
+ REG_VIDEOMEM = CONFIG_SYS_FPGA_OSD_MEM,
This has a certain smell to me - it smells like device
accesses based on a base + offset notation, which is not waht
we want to see. Why don't you use proper C structs instead
to describe your devices?
yup, got me. I know you prefer C struct based register access while we
don't. I'm sure anyone has excellent reasons for his opinion, and I
don't want to start a discussion here which would probably lead nowhere.
So, if you insist, I will convert our code to C struct based access.
Maybe you could point me to a nice clean implementation in u-boot, so I
can use the semantics you prefer (e.g. how holes in address space are
labeled).
Best regards,
Wolfgang Denk
Cheers
Dirk
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Fix defines needed to enable command sha1sum
Documented is CONFIG_CMD_SHA1, through confusion in the source
CONFIG_CMD_SHA1 and CONFIG_CMD_SHA1SUM has to be used to enable
sha1sum.
Fix both, the documentation and the source, so that only
CONFIG_CMD_SHA1SUM is needed to enable the command sha1sum.
Signed-off-by: Alexander Holler hol...@ahsoftware.de
---
README |2 +-
common/cmd_mem.c |4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/README b/README
index 8e1a9ff..755d17c 100644
--- a/README
+++ b/README
@@ -675,7 +675,7 @@ The following options need to be configured:
(requires CONFIG_CMD_I2C)
CONFIG_CMD_SETGETDCR Support for DCR Register access
(4xx only)
- CONFIG_CMD_SHA1 print sha1 memory digest
+ CONFIG_CMD_SHA1SUMprint sha1 memory digest
(requires CONFIG_CMD_MEMORY)
CONFIG_CMD_SOURCE source command Support
CONFIG_CMD_SPI * SPI serial bus support
diff --git a/common/cmd_mem.c b/common/cmd_mem.c
index f03233c..ccf420a 100644
--- a/common/cmd_mem.c
+++ b/common/cmd_mem.c
@@ -1184,7 +1184,7 @@ int do_md5sum(cmd_tbl_t *cmdtp, int flag, int argc, char
* const argv[])
}
#endif
-#ifdef CONFIG_CMD_SHA1
+#ifdef CONFIG_CMD_SHA1SUM
int do_sha1sum(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
unsigned long addr, len;
@@ -1343,7 +1343,7 @@ U_BOOT_CMD(
compute SHA1 message digest,
address count
);
-#endif /* CONFIG_CMD_SHA1 */
+#endif /* CONFIG_CMD_SHA1SUM */
#ifdef CONFIG_CMD_UNZIP
U_BOOT_CMD(
--
1.7.3.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] spi: add support SuperH SPI module
SH7757 has SPI module. This patch supports it.
Signed-off-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com
---
about v2:
- add prefix of SH_ to some defines.
- modify spi_cs_is_valid()
drivers/spi/Makefile |1 +
drivers/spi/sh_spi.c | 301 ++
2 files changed, 302 insertions(+), 0 deletions(-)
create mode 100644 drivers/spi/sh_spi.c
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index e34a124..d582fbb 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -37,6 +37,7 @@ COBJS-$(CONFIG_MPC8XXX_SPI) += mpc8xxx_spi.o
COBJS-$(CONFIG_MXC_SPI) += mxc_spi.o
COBJS-$(CONFIG_OMAP3_SPI) += omap3_spi.o
COBJS-$(CONFIG_SOFT_SPI) += soft_spi.o
+COBJS-$(CONFIG_SH_SPI) += sh_spi.o
COBJS := $(COBJS-y)
SRCS := $(COBJS:.o=.c)
diff --git a/drivers/spi/sh_spi.c b/drivers/spi/sh_spi.c
new file mode 100644
index 000..633450c
--- /dev/null
+++ b/drivers/spi/sh_spi.c
@@ -0,0 +1,301 @@
+/*
+ * SH SPI driver
+ *
+ * Copyright (C) 2011 Renesas Solutions Corp.
+ *
+ * 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; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ *
+ */
+
+#include common.h
+#include malloc.h
+#include spi.h
+#include asm/io.h
+
+#define SH_SPI_TBR 0x00
+#define SH_SPI_RBR 0x00
+#define SH_SPI_CR1 0x08
+#define SH_SPI_CR2 0x10
+#define SH_SPI_CR3 0x18
+#define SH_SPI_CR4 0x20
+
+/* CR1 */
+#define SH_SPI_TBE 0x80
+#define SH_SPI_TBF 0x40
+#define SH_SPI_RBE 0x20
+#define SH_SPI_RBF 0x10
+#define SH_SPI_PFONRD 0x08
+#define SH_SPI_SSDB0x04
+#define SH_SPI_SSD 0x02
+#define SH_SPI_SSA 0x01
+
+/* CR2 */
+#define SH_SPI_RSTF0x80
+#define SH_SPI_LOOPBK 0x40
+#define SH_SPI_CPOL0x20
+#define SH_SPI_CPHA0x10
+#define SH_SPI_L1M00x08
+
+/* CR3 */
+#define SH_SPI_MAX_BYTE0xFF
+
+/* CR4 */
+#define SH_SPI_TBEI0x80
+#define SH_SPI_TBFI0x40
+#define SH_SPI_RBEI0x20
+#define SH_SPI_RBFI0x10
+#define SH_SPI_WPABRT 0x04
+#define SH_SPI_SSS 0x01
+
+#define SH_SPI_FIFO_SIZE 32
+
+static void sh_spi_write(unsigned long data, unsigned long offset)
+{
+ writel(data, CONFIG_SH_SPI_BASE + offset);
+}
+
+static unsigned long sh_spi_read(unsigned long offset)
+{
+ return readl(CONFIG_SH_SPI_BASE + offset);
+}
+
+static void sh_spi_set_bit(unsigned long val, unsigned long offset)
+{
+ unsigned long tmp;
+
+ tmp = sh_spi_read(offset);
+ tmp |= val;
+ sh_spi_write(tmp, offset);
+}
+
+static void sh_spi_clear_bit(unsigned long val, unsigned long offset)
+{
+ unsigned long tmp;
+
+ tmp = sh_spi_read(offset);
+ tmp = ~val;
+ sh_spi_write(tmp, offset);
+}
+
+static void clear_fifo(void)
+{
+ sh_spi_set_bit(SH_SPI_RSTF, SH_SPI_CR2);
+ sh_spi_clear_bit(SH_SPI_RSTF, SH_SPI_CR2);
+}
+
+static int recvbuf_wait(void)
+{
+ while (sh_spi_read(SH_SPI_CR1) SH_SPI_RBE) {
+ if (ctrlc())
+ return 1;
+ udelay(10);
+ }
+ return 0;
+}
+
+static int write_fifo_full_wait(void)
+{
+ while (sh_spi_read(SH_SPI_CR1) SH_SPI_TBF) {
+ udelay(10);
+ if (ctrlc())
+ return 1;
+ }
+ return 0;
+}
+
+static int write_fifo_empty_wait(void)
+{
+ while (!(sh_spi_read(SH_SPI_CR1) SH_SPI_TBE)) {
+ if (ctrlc())
+ return 1;
+ udelay(10);
+ }
+ return 0;
+}
+
+void spi_init(void)
+{
+
+}
+
+struct spi_slave *spi_setup_slave(unsigned int bus, unsigned int cs,
+ unsigned int max_hz, unsigned int mode)
+{
+ struct spi_slave *slave;
+
+ if (!spi_cs_is_valid(bus, cs))
+ return NULL;
+
+ slave = malloc(sizeof(struct spi_slave));
+ if (!slave)
+ return NULL;
+
+ slave-bus = bus;
+ slave-cs = cs;
+
+ /* SPI sycle stop */
+ sh_spi_write(0xfe, SH_SPI_CR1);
+ /* CR1 init */
+ sh_spi_write(0x00, SH_SPI_CR1);
+ /* CR3 init */
+ sh_spi_write(0x00, SH_SPI_CR3);
+
+ clear_fifo();
+
+ /* 1/8 clock */
+ sh_spi_write(sh_spi_read(SH_SPI_CR2) | 0x07, SH_SPI_CR2);
+ udelay(10);
+
+ return slave;
+}
+
+void spi_free_slave(struct spi_slave *slave)
+{
+ free(slave);
+}
+
+int spi_claim_bus(struct spi_slave *slave)
+{
+
[U-Boot] [PATCH v2] net: sh_eth: add support for SH7757's ETHER
SH7757 has ETHER and GETHER. This patch supports EHTER only.
Signed-off-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com
---
about v2:
- remove unnecessary variable in sh_eth_config().
drivers/net/sh_eth.c | 37 +-
drivers/net/sh_eth.h | 53 +++--
2 files changed, 86 insertions(+), 4 deletions(-)
diff --git a/drivers/net/sh_eth.c b/drivers/net/sh_eth.c
index 53d918d..17dd0d2 100644
--- a/drivers/net/sh_eth.c
+++ b/drivers/net/sh_eth.c
@@ -277,6 +277,7 @@ int sh_eth_recv(struct eth_device *dev)
static int sh_eth_reset(struct sh_eth_dev *eth)
{
int port = eth-port;
+#if defined(CONFIG_CPU_SH7763)
int ret = 0, i;
/* Start e-dmac transmitter and receiver */
@@ -296,6 +297,13 @@ static int sh_eth_reset(struct sh_eth_dev *eth)
}
return ret;
+#else
+ outl(inl(EDMR(port)) | EDMR_SRST, EDMR(port));
+ udelay(3000);
+ outl(inl(EDMR(port)) ~EDMR_SRST, EDMR(port));
+
+ return 0;
+#endif
}
static int sh_eth_tx_desc_init(struct sh_eth_dev *eth)
@@ -339,9 +347,11 @@ static int sh_eth_tx_desc_init(struct sh_eth_dev *eth)
/* Point the controller to the tx descriptor list. Must use physical
addresses */
outl(ADDR_TO_PHY(port_info-tx_desc_base), TDLAR(port));
+#if defined(CONFIG_CPU_SH7763)
outl(ADDR_TO_PHY(port_info-tx_desc_base), TDFAR(port));
outl(ADDR_TO_PHY(cur_tx_desc), TDFXR(port));
outl(0x01, TDFFR(port));/* Last discriptor bit */
+#endif
err:
return ret;
@@ -405,9 +415,11 @@ static int sh_eth_rx_desc_init(struct sh_eth_dev *eth)
/* Point the controller to the rx descriptor list */
outl(ADDR_TO_PHY(port_info-rx_desc_base), RDLAR(port));
+#if defined(CONFIG_CPU_SH7763)
outl(ADDR_TO_PHY(port_info-rx_desc_base), RDFAR(port));
outl(ADDR_TO_PHY(cur_rx_desc), RDFXR(port));
outl(RDFFR_RDLF, RDFFR(port));
+#endif
return ret;
@@ -532,11 +544,18 @@ static int sh_eth_config(struct sh_eth_dev *eth, bd_t *bd)
outl(0, TFTR(port));
outl((FIFO_SIZE_T | FIFO_SIZE_R), FDR(port));
outl(RMCR_RST, RMCR(port));
+#ifndef CONFIG_CPU_SH7757
outl(0, RPADIR(port));
+#endif
outl((FIFO_F_D_RFF | FIFO_F_D_RFD), FCFTR(port));
/* Configure e-mac registers */
+#if defined(CONFIG_CPU_SH7757)
+ outl(ECSIPR_BRCRXIP | ECSIPR_PSRTOIP | ECSIPR_LCHNGIP |
+ ECSIPR_MPDIP | ECSIPR_ICDIP, ECSIPR(port));
+#else
outl(0, ECSIPR(port));
+#endif
/* Set Mac address */
val = dev-enetaddr[0] 24 | dev-enetaddr[1] 16 |
@@ -547,11 +566,16 @@ static int sh_eth_config(struct sh_eth_dev *eth, bd_t *bd)
outl(val, MALR(port));
outl(RFLR_RFL_MIN, RFLR(port));
+#ifndef CONFIG_CPU_SH7757
outl(0, PIPR(port));
+#endif
outl(APR_AP, APR(port));
outl(MPR_MP, MPR(port));
+#ifdef CONFIG_CPU_SH7757
+ outl(TPAUSER_UNLIMITED, TPAUSER(port));
+#else
outl(TPAUSER_TPAUSE, TPAUSER(port));
-
+#endif
/* Configure phy */
ret = sh_eth_phy_config(eth);
if (ret) {
@@ -562,6 +586,7 @@ static int sh_eth_config(struct sh_eth_dev *eth, bd_t *bd)
phy_status = sh_eth_mii_read_phy_reg(port, port_info-phy_addr, 1);
/* Set the transfer speed */
+#ifdef CONFIG_CPU_SH7763
if (phy_status (PHY_S_100X_F|PHY_S_100X_H)) {
printf(SHETHER_NAME : 100Base/);
outl(GECMR_100B, GECMR(port));
@@ -569,6 +594,16 @@ static int sh_eth_config(struct sh_eth_dev *eth, bd_t *bd)
printf(SHETHER_NAME : 10Base/);
outl(GECMR_10B, GECMR(port));
}
+#endif
+#if defined(CONFIG_CPU_SH7757)
+ if (phy_status (PHY_S_100X_F|PHY_S_100X_H)) {
+ printf(100Base/);
+ outl(1, RTRATE(port));
+ } else {
+ printf(10Base/);
+ outl(0, RTRATE(port));
+ }
+#endif
/* Check if full duplex mode is supported by the phy */
if (phy_status (PHY_S_100X_F|PHY_S_10T_F)) {
diff --git a/drivers/net/sh_eth.h b/drivers/net/sh_eth.h
index e153849..51e5d5b 100644
--- a/drivers/net/sh_eth.h
+++ b/drivers/net/sh_eth.h
@@ -1,5 +1,5 @@
/*
- * sh_eth.h - Driver for Renesas SH7763's gigabit ethernet controler.
+ * sh_eth.h - Driver for Renesas SuperH ethernet controler.
*
* Copyright (C) 2008 Renesas Solutions Corp.
* Copyright (c) 2008 Nobuhiro Iwamatsu
@@ -30,7 +30,11 @@
#define ADDR_TO_P2(addr) int)(addr) ~0xe000) | 0xa000))
/* The ethernet controller needs to use physical addresses */
+#if defined(CONFIG_SH_32BIT)
+#define ADDR_TO_PHY(addr) int)(addr) ~0xe000) | 0x4000))
+#else
#define ADDR_TO_PHY(addr) ((int)(addr) ~0xe000)
+#endif
/* Number of supported ports */
#define MAX_PORT_NUM 2
@@ -93,6 +97,7 @@ struct sh_eth_dev {
};
/* Register Address */
+#ifdef CONFIG_CPU_SH7763
[U-Boot] [PATCH v2] sh: add support for sh7757lcr board
The R0P7757LC0030RL board has SH7757, 256MB DDR3-SDRAM, SPI ROM, Ethernet, and more. This patch supports the following functions: - 256MB DDR3-SDRAM - SPI ROM - Ethernet Signed-off-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com --- about v2: - remove unnecessary comment in config.mk - move CONFIG_SYS_TEXT_BASE to include/configs/sh7757lcr.h - replace local parse function with eth_parse_enetaddr() - add NULL checking for malloc. - update copyright in u-boot.lds arch/sh/include/asm/cpu_sh4.h |2 + arch/sh/include/asm/cpu_sh7757.h| 263 +++ board/renesas/sh7757lcr/Makefile| 42 +++ board/renesas/sh7757lcr/config.mk | 26 ++ board/renesas/sh7757lcr/lowlevel_init.S | 558 +++ board/renesas/sh7757lcr/sh7757lcr.c | 432 board/renesas/sh7757lcr/spi-boot.c | 111 ++ board/renesas/sh7757lcr/u-boot.lds | 101 ++ boards.cfg |1 + doc/README.sh7757lcr| 64 include/configs/sh7757lcr.h | 145 11 files changed, 1745 insertions(+), 0 deletions(-) create mode 100644 arch/sh/include/asm/cpu_sh7757.h create mode 100644 board/renesas/sh7757lcr/Makefile create mode 100644 board/renesas/sh7757lcr/config.mk create mode 100644 board/renesas/sh7757lcr/lowlevel_init.S create mode 100644 board/renesas/sh7757lcr/sh7757lcr.c create mode 100644 board/renesas/sh7757lcr/spi-boot.c create mode 100644 board/renesas/sh7757lcr/u-boot.lds create mode 100644 doc/README.sh7757lcr create mode 100644 include/configs/sh7757lcr.h diff --git a/arch/sh/include/asm/cpu_sh4.h b/arch/sh/include/asm/cpu_sh4.h index fdcebd6..9b29d3a 100644 --- a/arch/sh/include/asm/cpu_sh4.h +++ b/arch/sh/include/asm/cpu_sh4.h @@ -44,6 +44,8 @@ # include asm/cpu_sh7722.h #elif defined (CONFIG_CPU_SH7723) # include asm/cpu_sh7723.h +#elif defined (CONFIG_CPU_SH7757) +# include asm/cpu_sh7757.h #elif defined (CONFIG_CPU_SH7763) # include asm/cpu_sh7763.h #elif defined (CONFIG_CPU_SH7780) diff --git a/arch/sh/include/asm/cpu_sh7757.h b/arch/sh/include/asm/cpu_sh7757.h new file mode 100644 index 000..eb9ff5b --- /dev/null +++ b/arch/sh/include/asm/cpu_sh7757.h @@ -0,0 +1,263 @@ +/* + * Copyright (C) 2009 Renesas Solutions Corp. + * + * 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 + * + */ + +#ifndef _ASM_CPU_SH7757_H_ +#define _ASM_CPU_SH7757_H_ + +#define CCR0xFF1C +#define WTCNT 0xFFCC +#define CCR_CACHE_INIT 0x090b +#defineCACHE_OC_NUM_WAYS 1 + +/* Exception */ +#define EXPEVT 0xff24 +#define INTEVT 0xff28 + +/* Watchdog */ +#define WTCSR0 0xffcc0002 +#define WRSTCSR_R 0xffcc0003 +#define WRSTCSR_W 0xffcc0002 +#define WTCSR_PREFIX 0xa500 +#define WRSTCSR_PREFIX 0x6900 +#define WRSTCSR_WOVF_PREFIX0x9600 + + +/* SCIF */ +#define SCIF0_BASE 0xfe4b /* The real name is SCIF2 */ +#define SCIF1_BASE 0xfe4c /* The real name is SCIF3 */ +#define SCIF2_BASE 0xfe4d /* The real name is SCIF4 */ + +/* SerMux */ +#define SMR0 0xfe47 + +/* TMU0 */ +#define TSTR 0xFE430004 +#define TOCR 0xFE43 +#define TSTR0 0xFE430004 +#define TCOR0 0xFE430008 +#define TCNT0 0xFE43000C +#define TCR0 0xFE430010 +#define TCOR1 0xFE430014 +#define TCNT1 0xFE430018 +#define TCR1 0xFE43001C +#define TCOR2 0xFE430020 +#define TCNT2 0xFE430024 +#define TCR2 0xFE430028 +#define TCPR2 0xFE43002C + +/* BSC */ +#define BCR0xFE801000 +#define CS0BCR 0xFF802000 +#define CS0WCR 0xFF802008 +#define CS4BCR 0xFF802040 +#define CS4WCR 0xFF802048 +#define CS5BCR 0xFF802050 +#define CS5WCR 0xFF802058 +#define CS6BCR 0xFF802060 +#define CS6WCR 0xFF802068 + +/* DDR3IF */ +#define DDR3IF_BASE0xfe80 +#define DBSTATE0 (DDR3IF_BASE + 0x0008) +#define DBSTATE1 (DDR3IF_BASE + 0x000c) +#define DBACEN (DDR3IF_BASE + 0x0010) +#define DBRFEN (DDR3IF_BASE + 0x0014) +#define DBCMD (DDR3IF_BASE + 0x0018) +#define
Re: [U-Boot] [RFC PATCH] ARM: print gcc version
Hello, Am 17.01.2011 23:28, schrieb Wolfgang Denk: Anyway, I would found it a nice feature, at startup or when running the version command, but both aren't a must. I think it would be a really useful extension to the version command. Looking forwad to seeing your patch. Maybe if someone could feed me with what to use for the version. E.g. my gcc here defines __VERSION__ as 4.5.2 but when I'm looking at u-boot/lib/asm-offsets.s I see .ident GCC: (Gentoo 4.5.2 p1.0, pie-0.4.5) 4.5.2 So I would like to display that which would be in line with the comment section of generated binaries. But when I use gcc -E -dM empty.c to print all predefined macros, I don't see the text found in .ident. Not even something else which includes Gentoo. Regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/8] armv7: adapt omap3 to the new cache maintenance framework
Dear Aneesh V,
In message 4d3525cd.8090...@ti.com you wrote:
+struct __attribute__ ((__packed__)) emu_hal_params {
+u32 num_params;
+u32 param1;
+};
Why exactly do we need the __attribute__ ((__packed__)) here?
Because a pointer to it has to be passed to ROM code and ROM code
wouldn't expect any padding.
But padding would only be needed if there were any alignment
requirements requiring it. There are none here.
Yes. But, is that guaranteed? I didn't want to make it compiler
Well, there has never been a guarantee agains broken tools doing
stupid or plain wrong things.
dependent. Isn't it safer to use '__attribute__ ((__packed__))'
'__attribute__ ((__packed__))' has (especially on ARM) certain
side-effects that are neither needed nor wanted here, I think.
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
Knowledge, sir, should be free to all!
-- Harry Mudd, I, Mudd, stardate 4513.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 7/8] imximage: Add MX53 boot image support
Dear Stefano Babic, In message 4d353d72.10...@denx.de you wrote: it is too late, it was already pulled. We need now a patch on top of this. Jason, can you check Wolfgang's comments and send a patch to fix the issues he reported ? It is not too late. I will not pull this into mainline as is. You can rebase your tree. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de ...one of the main causes of the fall of the Roman Empire was that, lacking zero, they had no way to indicate successful termination of their C programs. - Robert Firth ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] spi: add support SuperH SPI module
Dear Yoshihiro Shimoda,
In message 4d33c089.8040...@renesas.com you wrote:
SH7757 has SPI module. This patch supports it.
Signed-off-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com
---
drivers/spi/Makefile |1 +
drivers/spi/sh_spi.c | 295
++
2 files changed, 296 insertions(+), 0 deletions(-)
create mode 100644 drivers/spi/sh_spi.c
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index e34a124..d582fbb 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -37,6 +37,7 @@ COBJS-$(CONFIG_MPC8XXX_SPI) += mpc8xxx_spi.o
COBJS-$(CONFIG_MXC_SPI) += mxc_spi.o
COBJS-$(CONFIG_OMAP3_SPI) += omap3_spi.o
COBJS-$(CONFIG_SOFT_SPI) += soft_spi.o
+COBJS-$(CONFIG_SH_SPI) += sh_spi.o
Please keep list sorted.
diff --git a/drivers/spi/sh_spi.c b/drivers/spi/sh_spi.c
new file mode 100644
index 000..89ea5e2
--- /dev/null
+++ b/drivers/spi/sh_spi.c
...
+#define SPI_TBR 0x00
+#define SPI_RBR 0x00
+#define SPI_CR1 0x08
+#define SPI_CR2 0x10
+#define SPI_CR3 0x18
+#define SPI_CR4 0x20
Please declare a poper C struct instead.
+/* CR1 */
+#define SPI_TBE 0x80
+#define SPI_TBF 0x40
+#define SPI_RBE 0x20
+#define SPI_RBF 0x10
+#define SPI_PFONRD 0x08
+#define SPI_SSDB 0x04
+#define SPI_SSD 0x02
+#define SPI_SSA 0x01
+
+/* CR2 */
+#define SPI_RSTF 0x80
+#define SPI_LOOPBK 0x40
+#define SH_SPI_CPOL 0x20
+#define SH_SPI_CPHA 0x10
+#define SPI_L1M0 0x08
+
+/* CR3 */
+#define SPI_MAX_BYTE 0xFF
+
+/* CR4 */
+#define SPI_TBEI 0x80
+#define SPI_TBFI 0x40
+#define SPI_RBEI 0x20
+#define SPI_RBFI 0x10
+#define SPI_WPABRT 0x04
+#define SPI_SSS 0x01
+
+#define SPI_FIFO_SIZE32
All this stuff should better go into a separate header file.
+static void sh_spi_write(unsigned long data, unsigned long offset)
+{
+ writel(data, CONFIG_SH_SPI_BASE + offset);
NAK. We do not allow the base + offset notation. Pleaseuse a proper
C struct instead.
Please fix globally.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
When the only tool you have is a hammer, you tend to treat
everything as if it were a nail.- Abraham Maslow
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] add checking the CONFIG_ENV_IS_IN_SPI_FLASH in Enbedded env
Dear Yoshihiro Shimoda, In message 4d33c078.3090...@renesas.com you wrote: Fix the problem which cannot build the U-boot, if we only set the CONFIG_ENV_IS_IN_SPI_FLASH. Signed-off-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com --- include/environment.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/environment.h b/include/environment.h index 082b3e1..8a4f393 100644 --- a/include/environment.h +++ b/include/environment.h @@ -106,6 +106,7 @@ extern unsigned long nand_env_oob_offset; /* Embedded env is only supported for some flash types */ #ifdef CONFIG_ENV_IS_EMBEDDED # if !defined(CONFIG_ENV_IS_IN_FLASH) \ + !defined(CONFIG_ENV_IS_IN_SPI_FLASH) \ !defined(CONFIG_ENV_IS_IN_NAND) \ !defined(CONFIG_ENV_IS_IN_ONENAND) Please keep list sorted. 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 Randal said it would be tough to do in sed. He didn't say he didn't understand sed. Randal understands sed quite well. Which is why he uses Perl. :-) - Larry Wall in 7...@jpl-devvax.jpl.nasa.gov ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] net: sh_eth: add cache handling
Dear Nobuhiro Iwamatsu, In message 20110117130531.gd13...@chimagu.nigauri.org you wrote: On Mon, Jan 17, 2011 at 01:08:58PM +0900, Yoshihiro Shimoda wrote: Some CPU needs cache handling. So this patch add the config of CONFIG_SH_ETHER_CACHE_WRITEBACK, and it calls wback function. Signed-off-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com --- drivers/net/sh_eth.c |9 + 1 files changed, 9 insertions(+), 0 deletions(-) Applied, thank. You are a bit fast. Network code should go throughthe network custodian, or at least it requires his ACK. 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 How does a project get to be a year late? ... One day at a time. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] net: sh_eth: add cache handling
Dear Yoshihiro Shimoda, In message 4d33c0da.4000...@renesas.com you wrote: Some CPU needs cache handling. So this patch add the config of CONFIG_SH_ETHER_CACHE_WRITEBACK, and it calls wback function. Signed-off-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com --- drivers/net/sh_eth.c |9 + 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/drivers/net/sh_eth.c b/drivers/net/sh_eth.c index 86cc324..53d918d 100644 --- a/drivers/net/sh_eth.c +++ b/drivers/net/sh_eth.c @@ -36,6 +36,12 @@ #ifndef CONFIG_SH_ETHER_PHY_ADDR # error Please define CONFIG_SH_ETHER_PHY_ADDR #endif +#ifdef CONFIG_SH_ETHER_CACHE_WRITEBACK +#define flush_cache_wback(addr, len) \ + dcache_wback_range((u32)addr, (u32)(addr + len - 1)) +#else +#define flush_cache_wback(...) +#endif New config options must be documented in the README. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de When all is said and done, more is said than done. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sh: add support for sh7757lcr board
Dear Nobuhiro Iwamatsu, In message 20110117125040.gb13...@chimagu.nigauri.org you wrote: On Mon, Jan 17, 2011 at 01:11:08PM +0900, Yoshihiro Shimoda wrote: The R0P7757LC0030RL board has SH7757, 256MB DDR3-SDRAM, SPI ROM, Ethernet, and more. This patch supports the following functions: - 256MB DDR3-SDRAM - SPI ROM - Ethernet Signed-off-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com ... ~ 400 lines of full quote deleted. +LDSCRIPT = $(OBJTREE)/board/$(BOARDDIR)/u-boot.lds +#sinclude $(OBJTREE)/board/$(BOARDDIR)/config.tmp + Is this nesseary? Could you please only quote the lines you are referring to? It is difficult to find your comments when you quote the whole, long patch. Thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Men will always be men -- no matter where they are. -- Harry Mudd, Mudd's Women, stardate 1329.8 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sh: add support for sh7757lcr board
Dear Yoshihiro Shimoda, In message 4d3547b8.6020...@renesas.com you wrote: Is this nesseary? The #sinclude is not nessesary. I will remove it. However the LDSCRIPT is necessary on this board because the LSI needs the top of address when booting. Please ditch the whole config.mk file and define LDSCRIPT in your board config file. 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 Security is mostly a superstition. It does not exist in nature... Life is either a daring adventure or nothing. - Helen Keller ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-mpc85xx.git
(forgot the subject ;) - k On Jan 17, 2011, at 10:45 PM, Kumar Gala wrote: The following changes since commit e1ccf97c5d7651664d37c0c5aa243874b8851b2d: Merge branch 'master' of git://git.denx.de/u-boot-mpc85xx (2011-01-17 20:31:46 +0100) are available in the git repository at: git://git.denx.de/u-boot-mpc85xx master Haiying Wang (1): 8xxx/ddr: add support to only compute the ddr sdram size Kumar Gala (4): powerpc/85xx: Move RESET_VECTOR_ADDRESS into config.h powerpc/p3041: Add various p3041 specific information powerpc/p5020: Add various p5020 specific information powerpc/p2040: Add various p2040 specific information Poonam Aggrwal (2): powerpc/85xx: Add Support for Freescale P1010 Processor powerpc/85xx: Add Support for Freescale P1014 Processor Prabhakar (1): Fix wrong CONFIG_SYS_MPC85xx_SERDES1_ADDR arch/powerpc/cpu/mpc85xx/Makefile|6 + arch/powerpc/cpu/mpc85xx/p2040_serdes.c | 66 + arch/powerpc/cpu/mpc85xx/p3041_ids.c | 105 + arch/powerpc/cpu/mpc85xx/p3041_serdes.c | 151 ++ arch/powerpc/cpu/mpc85xx/p5020_ids.c | 105 + arch/powerpc/cpu/mpc85xx/p5020_serdes.c | 151 ++ arch/powerpc/cpu/mpc85xx/u-boot.lds |8 +- arch/powerpc/cpu/mpc8xxx/cpu.c |6 + arch/powerpc/cpu/mpc8xxx/ddr/ctrl_regs.c | 10 ++- arch/powerpc/cpu/mpc8xxx/ddr/ddr.h |8 +- arch/powerpc/cpu/mpc8xxx/ddr/main.c | 31 +- arch/powerpc/include/asm/config.h| 10 ++- arch/powerpc/include/asm/immap_85xx.h|2 +- arch/powerpc/include/asm/processor.h |6 + board/freescale/corenet_ds/config.mk | 27 -- board/freescale/mpc8536ds/config.mk | 14 +--- board/freescale/mpc8572ds/config.mk |2 - board/freescale/p1022ds/config.mk| 10 -- board/freescale/p1_p2_rdb/config.mk | 12 --- board/freescale/p2020ds/config.mk| 26 - drivers/misc/fsl_law.c |7 +- include/configs/MPC8536DS.h |6 + include/configs/MPC8572DS.h |4 + include/configs/P1022DS.h|4 + include/configs/P1_P2_RDB.h |6 + include/configs/P2020DS.h|4 + include/configs/corenet_ds.h |4 + 27 files changed, 683 insertions(+), 108 deletions(-) create mode 100644 arch/powerpc/cpu/mpc85xx/p2040_serdes.c create mode 100644 arch/powerpc/cpu/mpc85xx/p3041_ids.c create mode 100644 arch/powerpc/cpu/mpc85xx/p3041_serdes.c create mode 100644 arch/powerpc/cpu/mpc85xx/p5020_ids.c create mode 100644 arch/powerpc/cpu/mpc85xx/p5020_serdes.c delete mode 100644 board/freescale/corenet_ds/config.mk delete mode 100644 board/freescale/p1022ds/config.mk delete mode 100644 board/freescale/p2020ds/config.mk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/7] Add support for Freescale's mx35pdk board.
Dear Stefano Babic, In message 4d34744b.2030...@denx.de you wrote: I have not understood this point. The link address CONFIG_SYS_TEXT_BASE is always set in the config.mk file, because it is needed by the linker process, and it is not set in the configuration file (I think you mean mx35pdk.h). All boards follow this rule. If I move it, the linker does not find it. Do you mean probably something else ? No, you are wrong. CONFIG_SYS_TEXT_BASE is always set in the configuration file, only a few files still have it in config.mk - these files need to be cleand up, and ideally config.mk should be ditched. 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 Beware of the Turing Tar-pit in which everything is possible but nothing of interest is easy. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6] mpq101: initial support for Mercury Computer Systems MPQ101 board
On Jan 18, 2011, at 2:03 AM, Alex Dubov wrote: +/* + * For booting Linux, the board info and command line data + * have to be in the first 16 MB of memory, since this is + * the maximum mapped by the Linux kernel during initialization. + */ +#define CONFIG_SYS_BOOTMAPSZ (16 20) /* Initial Memory map for Linux*/ + You might also want to set: #define CONFIG_SYS_BOOTM_LEN (16 20) /* Increase max gunzip size */ to match BOOTMAPSZ. Sorry, I keep nit picking ;) - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ppc4xx: Support dual link OSD
Dear Eibach, Dirk, In message 48d3d52125c49b43ae880038e2e5314bb5b...@srv101.gdsys.de you wrote: So, if you insist, I will convert our code to C struct based access. Please do. Maybe you could point me to a nice clean implementation in u-boot, so I can use the semantics you prefer (e.g. how holes in address space are labeled). Check out any of the PPC header files. Holes are usually marked as reserved - try for example grep reserved arch/powerpc/include/asm/* Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de A well-written program is its own heaven; a poorly-written program is its own hell. -- Geoffrey James, The Tao of Programming ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] spi: add support SuperH SPI module
Dear Yoshihiro Shimoda, In message 4d355516.6020...@renesas.com you wrote: SH7757 has SPI module. This patch supports it. Signed-off-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com --- about v2: - add prefix of SH_ to some defines. - modify spi_cs_is_valid() drivers/spi/Makefile |1 + drivers/spi/sh_spi.c | 301 ++ 2 files changed, 302 insertions(+), 0 deletions(-) create mode 100644 drivers/spi/sh_spi.c Please see my additional review comments to V1 of this and the other patches of this series. 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 In Nature there are neither rewards nor punishments, there are conse- quences.-- R.G. Ingersoll ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/7] Add support for Freescale's mx35pdk board.
On 01/18/2011 10:40 AM, Wolfgang Denk wrote: No, you are wrong. CONFIG_SYS_TEXT_BASE is always set in the configuration file, only a few files still have it in config.mk - these files need to be cleand up, and ideally config.mk should be ditched. I see, understood. I will drop config.mk. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 7/8] imximage: Add MX53 boot image support
On 01/18/2011 10:24 AM, Wolfgang Denk wrote: It is not too late. I will not pull this into mainline as is. You can rebase your tree. No problem on my side. Albert should also drop this patch, because it is already merged into u-boot-arm. I will wait for updates from Jason. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] SPI: mxc_spi: fix swapping bug and add missing swapping in unaligned rx case
On 01/16/2011 07:17 PM, Anatolij Gustschin wrote: We need to shift only one time in each cycle in the swapping loop for unaligned tx case. Currently two byte shift operations are performed in each loop cycle causing zero gaps in the transmited data, so not all data scheduled for transmition is actually transmited. Tested on a mx35pdk. Tested-by: Stefano Babic sba...@denx.de Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 2/2] SPI: mxc_spi: add SPI clock calculation and setup to the driver
From: Anatolij Gustschin ag...@denx.de
The MXC SPI driver didn't calculate the SPI clock up to
now and just highest possible divider 512 for DATA
RATE in the control register. This results in very low
transfer rates.
The patch adds code to calculate and setup the SPI clock
frequency for transfers.
Signed-off-by: Anatolij Gustschin ag...@denx.de
Signed-off-by: Stefano Babic sba...@denx.de
---
Changes:
The patch is rebased on the current patches already sent for this driver
(support for MX35). Tested on a MX35 board.
Modified commit message as suggested by Anatolij
drivers/spi/mxc_spi.c | 24 +++-
1 files changed, 23 insertions(+), 1 deletions(-)
diff --git a/drivers/spi/mxc_spi.c b/drivers/spi/mxc_spi.c
index 0e42d41..32be7b0 100644
--- a/drivers/spi/mxc_spi.c
+++ b/drivers/spi/mxc_spi.c
@@ -71,6 +71,7 @@ static unsigned long spi_bases[] = {
};
#define spi_cfgspi_cfg_mx3
+#define mxc_get_clock(x) mx31_get_ipg_clk()
#elif defined(CONFIG_MX51)
#include asm/arch/imx-regs.h
@@ -201,15 +202,36 @@ void spi_cs_deactivate(struct spi_slave *slave)
!(mxcs-ss_pol));
}
+u32 get_cspi_div(u32 div)
+{
+ int i;
+
+ for (i = 0; i 8; i++) {
+ if (div = (4 i))
+ return i;
+ }
+ return i;
+}
+
#if defined(CONFIG_MX31) || defined(CONFIG_MX35)
static s32 spi_cfg_mx3(struct mxc_spi_slave *mxcs, unsigned int cs,
unsigned int max_hz, unsigned int mode)
{
unsigned int ctrl_reg;
+ u32 clk_src;
+ u32 div;
+
+ clk_src = mxc_get_clock(MXC_CSPI_CLK);
+
+ div = clk_src / max_hz;
+ div = get_cspi_div(div);
+
+ debug(clk %d Hz, div %d, real clk %d Hz\n,
+ max_hz, div, clk_src / (4 div));
ctrl_reg = MXC_CSPICTRL_CHIPSELECT(cs) |
MXC_CSPICTRL_BITCOUNT(MXC_CSPICTRL_MAXBITS) |
- MXC_CSPICTRL_DATARATE(7) | /* FIXME: calculate data rate */
+ MXC_CSPICTRL_DATARATE(div) |
MXC_CSPICTRL_EN |
#ifdef CONFIG_MX35
MXC_CSPICTRL_SSCTL |
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot support for board(s) meesc, otc570
Dear Daniel Gorsulowski, Hello Albert, Albert ARIBAUD wrote: Le 18/01/2011 10:27, Daniel Gorsulowski a écrit : Hello again! Hi Daniel, One month ago, I asked you for help (see message below), but got no answer. Sorry about that. Last quarter of 2010 was rather busy for me. Do you see any chance, to fix the at91 tree? There is no way to fix my boards, as long as all at91 builds have fundamental problems. I found a patch series from Alexander Stein, but it seems, this series does not go mainline: http://lists.denx.de/pipermail/u-boot/2010-November/080885.html Should I ask Alexander for resend his pathes? Regards Daniel Reinhard (Cc:) has lots of fixes in his u-boot-atmel tree; you should try its master branch. I'm leaving below your (unanswered, apologies again) questions for Reinhard to answer. Regards, Albert. Thanks for your response! I tried Reinhards master branch, but build throws same errors as shown below. It seems, among other things the atmel usart driver needs an update to new SoC access. Alexander Steins patch series seems to add this support. I'll wait for a fix until I send patches for my boards. 1. Please send always the mailing list, too! 2. Use the rework101229 branch (minus the last 5 patches). There is lot of cleanup done in the header files and the ATMEL drivers. The at91sam9260(9xe)ek board builds fine and works. Use that as a template or reference what to do. You should *only* need to adapt board/*/files and your configs/board.h files. And of course updated entries in boards.cfg. Once the rework is done for *almost* *ALL* AT91 SoCs it will be put for review into mainline, probably for the 06.2011 U-Boot. Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Net: Add Intel E1000 82574L PCIe card support
Add Intel E1000 82574L PCIe card support. Test on MPC8544DS
and MPC8572 board.
Add the missing contact information for future support.
Signed-off-by: Roy Zang tie-fei.z...@freescale.com
---
based on commit e1ccf97c5d7651664d37c0c5aa243874b8851b2d
drivers/net/e1000.c | 35 +++
drivers/net/e1000.h | 11 +++
include/pci_ids.h |1 +
3 files changed, 39 insertions(+), 8 deletions(-)
diff --git a/drivers/net/e1000.c b/drivers/net/e1000.c
index 5f390bd..a545cd1 100644
--- a/drivers/net/e1000.c
+++ b/drivers/net/e1000.c
@@ -40,6 +40,10 @@ tested on both gig copper and gig fiber boards
* Copyright (C) Linux Networx.
* Massive upgrade to work with the new intel gigabit NICs.
* ebiederman at lnxi dot com
+ *
+ * Copyright 2009, 2011 Freescale Semiconductor, Inc.
+ * Authors: Roy Zang tie-fei.z...@freescale.com
+ * - Add PCI Express card support in Jul. 2009
*/
#include e1000.h
@@ -100,6 +104,7 @@ static struct pci_device_id supported[] = {
{PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82573E},
{PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82573E_IAMT},
{PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82573L},
+ {PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82574L},
{PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82546GB_QUAD_COPPER_KSP3},
{PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_80003ES2LAN_COPPER_DPT},
{PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_80003ES2LAN_SERDES_DPT},
@@ -331,7 +336,7 @@ static boolean_t e1000_is_onboard_nvm_eeprom(struct
e1000_hw *hw)
if (hw-mac_type == e1000_ich8lan)
return FALSE;
- if (hw-mac_type == e1000_82573) {
+ if (hw-mac_type == e1000_82573 || hw-mac_type == e1000_82574) {
eecd = E1000_READ_REG(hw, EECD);
/* Isolate bits 15 16 */
@@ -364,7 +369,7 @@ e1000_acquire_eeprom(struct e1000_hw *hw)
return -E1000_ERR_SWFW_SYNC;
eecd = E1000_READ_REG(hw, EECD);
- if (hw-mac_type != e1000_82573) {
+ if (hw-mac_type != e1000_82573 || hw-mac_type != e1000_82574) {
/* Request EEPROM Access */
if (hw-mac_type e1000_82544) {
eecd |= E1000_EECD_REQ;
@@ -498,6 +503,7 @@ static int32_t e1000_init_eeprom_params(struct e1000_hw *hw)
eeprom-use_eewr = FALSE;
break;
case e1000_82573:
+ case e1000_82574:
eeprom-type = e1000_eeprom_spi;
eeprom-opcode_bits = 8;
eeprom-delay_usec = 1;
@@ -1317,6 +1323,9 @@ e1000_set_mac_type(struct e1000_hw *hw)
case E1000_DEV_ID_82573L:
hw-mac_type = e1000_82573;
break;
+ case E1000_DEV_ID_82574L:
+ hw-mac_type = e1000_82574;
+ break;
case E1000_DEV_ID_80003ES2LAN_COPPER_SPT:
case E1000_DEV_ID_80003ES2LAN_SERDES_SPT:
case E1000_DEV_ID_80003ES2LAN_COPPER_DPT:
@@ -1487,6 +1496,7 @@ e1000_initialize_hardware_bits(struct e1000_hw *hw)
E1000_WRITE_REG(hw, TARC1, reg_tarc1);
break;
case e1000_82573:
+ case e1000_82574:
reg_ctrl_ext = E1000_READ_REG(hw, CTRL_EXT);
reg_ctrl_ext = ~(1 23);
reg_ctrl_ext |= (1 22);
@@ -1728,12 +1738,11 @@ e1000_init_hw(struct eth_device *nic)
| E1000_TXDCTL_FULL_TX_DESC_WB;
E1000_WRITE_REG(hw, TXDCTL1, ctrl);
break;
- }
-
- if (hw-mac_type == e1000_82573) {
- uint32_t gcr = E1000_READ_REG(hw, GCR);
- gcr |= E1000_GCR_L1_ACT_WITHOUT_L0S_RX;
- E1000_WRITE_REG(hw, GCR, gcr);
+ case e1000_82573:
+ case e1000_82574:
+ reg_data = E1000_READ_REG(hw, GCR);
+ reg_data |= E1000_GCR_L1_ACT_WITHOUT_L0S_RX;
+ E1000_WRITE_REG(hw, GCR, reg_data);
}
#if 0
@@ -1812,6 +1821,7 @@ e1000_setup_link(struct eth_device *nic)
switch (hw-mac_type) {
case e1000_ich8lan:
case e1000_82573:
+ case e1000_82574:
hw-fc = e1000_fc_full;
break;
default:
@@ -4560,6 +4570,9 @@ static int e1000_set_phy_type (struct e1000_hw *hw)
hw-phy_type = e1000_phy_gg82563;
break;
}
+ case BME1000_E_PHY_ID:
+ hw-phy_type = e1000_phy_bm ;
+ break;
/* Fall Through */
default:
/* Should never have loaded on this device */
@@ -4646,6 +4659,10 @@ e1000_detect_gig_phy(struct e1000_hw *hw)
if (hw-phy_id == M88E_I_PHY_ID)
match = TRUE;
break;
+ case e1000_82574:
+ if (hw-phy_id == BME1000_E_PHY_ID)
+
[U-Boot] [PATCH v3] ppc, 8xx: remove obsolete km8xx boards from keymile
From: Holger Brunck holger.bru...@keymile.com The MPC852 based mgsuvd and kmsupx4 boards from keymile were initially ported but later on not developed further. So the respective files were removed to avoid unneeded merging and maintenance. Signed-off-by: Holger Brunck holger.bru...@keymile.com Acked-by: Heiko Schocherh...@denx.de --- Changes for v3: - resend unchanged, because of corrupted lines in previous version Changes for v2: - fix typos in commit message - remove boards from MAINTAINERS file MAINTAINERS |2 - board/keymile/km8xx/Makefile | 48 - board/keymile/km8xx/km8xx.c | 197 --- board/keymile/km8xx/km8xx_hdlc_enet.c | 278 --- board/keymile/km8xx/u-boot.lds| 97 -- boards.cfg|2 - include/configs/km8xx.h | 332 - include/configs/kmsupx4.h | 43 - include/configs/mgsuvd.h | 40 9 files changed, 0 insertions(+), 1039 deletions(-) delete mode 100644 board/keymile/km8xx/Makefile delete mode 100644 board/keymile/km8xx/km8xx.c delete mode 100644 board/keymile/km8xx/km8xx_hdlc_enet.c delete mode 100644 board/keymile/km8xx/u-boot.lds delete mode 100644 include/configs/km8xx.h delete mode 100644 include/configs/kmsupx4.h delete mode 100644 include/configs/mgsuvd.h diff --git a/MAINTAINERS b/MAINTAINERS index a799037..a6e8a7f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -418,9 +418,7 @@ Heiko Schocher h...@denx.de ids8247 MPC8247 jupiter MPC5200 kmeter1 MPC8360 - kmsupx4 MPC852T mgcoge MPC8247 - mgsuvd MPC852 mucmc52 MPC5200 muas3001MPC8270 municse MPC5200 diff --git a/board/keymile/km8xx/Makefile b/board/keymile/km8xx/Makefile deleted file mode 100644 index abb9ef9..000 --- a/board/keymile/km8xx/Makefile +++ /dev/null @@ -1,48 +0,0 @@ -# -# (C) Copyright 2007 -# Heiko Schocher, DENX Software Engineering, h...@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 -ifneq ($(OBJTREE),$(SRCTREE)) -$(shell mkdir -p $(obj)../common) -endif - -LIB= $(obj)lib$(BOARD).o - -COBJS = $(BOARD).o ../common/common.o ../common/keymile_hdlc_enet.o \ - km8xx_hdlc_enet.o - -SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) -OBJS := $(addprefix $(obj),$(COBJS)) -SOBJS := $(addprefix $(obj),$(SOBJS)) - -$(LIB):$(obj).depend $(OBJS) - $(call cmd_link_o_target, $(OBJS)) - -# - -# defines $(obj).depend target -include $(SRCTREE)/rules.mk - -sinclude $(obj).depend - -# diff --git a/board/keymile/km8xx/km8xx.c b/board/keymile/km8xx/km8xx.c deleted file mode 100644 index 6de2f22..000 --- a/board/keymile/km8xx/km8xx.c +++ /dev/null @@ -1,197 +0,0 @@ -/* - * (C) Copyright 2007 - * Heiko Schocher, DENX Software Engineering, h...@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 common.h -#include mpc8xx.h -#include net.h -#include asm/io.h - -#if defined(CONFIG_OF_BOARD_SETUP) defined(CONFIG_OF_LIBFDT) -#include libfdt.h -#endif - -#include ../common/common.h - -DECLARE_GLOBAL_DATA_PTR; - -const uint
Re: [U-Boot] usage of DMA
Hi Marcel, Marcel wrote: I have already reduced the code quite far. Basically all dma related stuff is gone. According to your first message in this thread I suppose that you are using atmel_usba_udc driver. Am I right? Looks like it's able to use PIO mode transfer (I mean linux driver). Each EP has can_dma flag which can be passed through platform_data. So: 1) Could you please make sure that this driver is working in linux in PIO mode (with can_dma set to zero)? 2) Could you port this driver to u-boot w/o changes in functions that talk with hardware registers and try to use PIO mode (with can_dma set to zero and commented DMA function calls)? The device is recognised by the host without errors, but there are some issues left as the OUT data doesn't get processed by ether.c. After the device descriptor is received the host usually wants to setup the device. Has the setup stage been done? I'm pulling my hair on this one, but since the data arrives in the OUT fifo and I can read it from the controller part I guess all end points are really up and running but the interfacing to the gadget system maybe isn't correct. Perhaps that's related to the driver I'm porting which comes from a 2.6.33 kernel. 2.6.33 controller driver should be compatible with 2.6.24 gadget stack (which was ported to u-boot). I read quite a lot of the USB device specification for my controller and so far think I've done everything right regarding the registers. Nobody can be sure in such thing :) Even if everything works Could you enable debug output for ether.c and for your UDC driver and show the results? With best regards, Vitaly. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] usage of DMA
Hi Marcel, In addition, did you enable CONFIG_USB_GADGET_DUALSPEED option in your u-boot config file? With best regards, Vitaly. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Boot Count Limit Feature Query
Hi I am working with a TI Davinci DM365 and would love to use the boot count limit feature for a product that we are working on but the docs state it is only supported by Power Architecture processors. Could someone please explain why this is and how it works as I will need to either find an alternate solution or investigate implementing something similar for this project and would appreciate any insights. Regards Sean -- Sean Preston Software Engineer Email: se...@pfk.co.za ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Boot Count Limit Feature Query
Dear Sean Preston, In message 008901cbb715$9a371b10$cea55130$@pfk.co.za you wrote: I am working with a TI Davinci DM365 and would love to use the boot count limit feature for a product that we are working on but the docs state it is only supported by Power Architecture processors. Could someone please The fact that so far mostly (or only? don't know) PPC systems use this is that environments where such a feature is needed or useful often have pretty strict requirements in terms of reliability, robustness and long-time availability (think for example telecoms). PPC has traditionally been the preferred platform for such systems. For example, only pretty recently you can find ARM vendors that guarantee that a certain chip will be available in 10 years from now. explain why this is and how it works as I will need to either find an alternate solution or investigate implementing something similar for this project and would appreciate any insights. How it works? Please see the code. Basicly all you need is a 32 bit storage location in some register or SRAM or similar which is guaranteed not to change it's value during a (hard) reset of the board. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de You young'uns. That was *long* before AltaVista, DejaNews, or even (gasp) the *Web*! In fact, we typed that thread on steam-powered card punchers, and shipped it around via Pony Express. -- Randal Schwartz in 8cwww1cd0d@gadget.cscaper.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 7/8] imximage: Add MX53 boot image support
Hi, Wolfgang and Stefano, 2011/1/18 Wolfgang Denk w...@denx.de: Dear Stefano Babic, In message 4d353d72.10...@denx.de you wrote: it is too late, it was already pulled. We need now a patch on top of this. Jason, can you check Wolfgang's comments and send a patch to fix the issues he reported ? It is not too late. I will not pull this into mainline as is. You can rebase your tree. Do I need send out the new version patch for imximage to address Wolfgang's comments or send out the whole patchset(8patches) include the new version patch? What's the process for it? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de ...one of the main causes of the fall of the Roman Empire was that, lacking zero, they had no way to indicate successful termination of their C programs. - Robert Firth ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 7/8] imximage: Add MX53 boot image support
Dear Jason Liu, In message AANLkTingvggSztUuHQCzrxaOn04ZO=k07xfczkfci...@mail.gmail.com you wrote: Do I need send out the new version patch for imximage to address Wolfgang's comments or send out the whole patchset(8patches) include the new version patch? What's the process for it? If the changes affect only this one patch, then you can resubmit only this single patch. 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 How many hardware guys does it take to change a light bulb? Well the diagnostics say it's fine buddy, so it's a software problem. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 7/8] imximage: Add MX53 boot image support
Hi, Wolfgang, 2011/1/18 Wolfgang Denk w...@denx.de: Dear Jason Liu, In message AANLkTingvggSztUuHQCzrxaOn04ZO=k07xfczkfci...@mail.gmail.com you wrote: Do I need send out the new version patch for imximage to address Wolfgang's comments or send out the whole patchset(8patches) include the new version patch? What's the process for it? If the changes affect only this one patch, then you can resubmit only this single patch. This is the only one patch from the whole pathset(8patches) need get updated So, I just resubmit it with one newer version for only this patch, is it ok? 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 How many hardware guys does it take to change a light bulb? Well the diagnostics say it's fine buddy, so it's a software problem. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 7/8] imximage: Add MX53 boot image support
Am 18.01.2011 15:59, schrieb Jason Liu: Hi Jason, This is the only one patch from the whole pathset(8patches) need get updated So, I just resubmit it with one newer version for only this patch, is it ok? Yes, I agree. The other patches have received formal ACKs or there are no more comments for them, and I have integrated in u-boot-imx. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 2/2] SPI: mxc_spi: add SPI clock calculation and setup to the driver
Hello. Stefano Babic wrote: From: Anatolij Gustschin ag...@denx.de The MXC SPI driver didn't calculate the SPI clock up to now and just highest possible divider 512 for DATA ^ I think used shouldn't have been ommitted here. RATE in the control register. This results in very low transfer rates. The patch adds code to calculate and setup the SPI clock frequency for transfers. Signed-off-by: Anatolij Gustschin ag...@denx.de Signed-off-by: Stefano Babic sba...@denx.de WBR, Sergei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Coding Style question
In a header define register fields we have something like: +#define CSOR_NAND_TRHZ_MASK 0x001C /* Time for Read Enable +High to Output High +Impedance */ Is this multiple line comment style ok - since we are dealing with line wrap ? - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Net: Add Intel E1000 82574L PCIe card support
On Jan 18, 2011, at 5:55 AM, Roy Zang wrote: Add Intel E1000 82574L PCIe card support. Test on MPC8544DS and MPC8572 board. Add the missing contact information for future support. Signed-off-by: Roy Zang tie-fei.z...@freescale.com --- based on commit e1ccf97c5d7651664d37c0c5aa243874b8851b2d drivers/net/e1000.c | 35 +++ drivers/net/e1000.h | 11 +++ include/pci_ids.h |1 + 3 files changed, 39 insertions(+), 8 deletions(-) Acked-by: Kumar Gala ga...@kernel.crashing.org - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Do not copy elf section to same adress
When an elf section is already at the right position (e.g. after image
decompression by bootm) there is no need to copy it.
Signed-off-by: Matthias Weisser weiss...@arcor.de
---
common/cmd_elf.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/common/cmd_elf.c b/common/cmd_elf.c
index bf32612..aec4579 100644
--- a/common/cmd_elf.c
+++ b/common/cmd_elf.c
@@ -342,9 +342,10 @@ static unsigned long load_elf_image_shdr(unsigned long
addr)
memset ((void *)shdr-sh_addr, 0, shdr-sh_size);
} else {
image = (unsigned char *) addr + shdr-sh_offset;
- memcpy ((void *) shdr-sh_addr,
- (const void *) image,
- shdr-sh_size);
+ if ((void *) shdr-sh_addr != (void *) image)
+ memcpy((void *) shdr-sh_addr,
+ (const void *) image,
+ shdr-sh_size);
}
flush_cache (shdr-sh_addr, shdr-sh_size);
}
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] ARM: print gcc version
Anyway, I would found it a nice feature, at startup or when running the version command, but both aren't a must. I think it would be a really useful extension to the version command. Looking forwad to seeing your patch. Maybe if someone could feed me with what to use for the version. E.g. my gcc here defines __VERSION__ as 4.5.2 but when I'm looking at u-boot/lib/asm-offsets.s I see .ident GCC: (Gentoo 4.5.2 p1.0, pie-0.4.5) 4.5.2 So I would like to display that which would be in line with the comment section of generated binaries. But when I use gcc -E -dM empty.c to print all predefined macros, I don't see the text found in .ident. Not even something else which includes Gentoo. I believe the output of $(CC) --version should contain the same data as your .ident string. You could echo it into a file like: diff --git a/Makefile b/Makefile index 0685ef9..e070d40 100644 --- a/Makefile +++ b/Makefile @@ -416,6 +416,8 @@ $(U_BOOT_ONENAND): $(ONENAND_IPL) $(obj)u-boot.bin $(VERSION_FILE): @( printf '#define U_BOOT_VERSION U-Boot %s%s\n' $(U_BOOT_VERSION) \ '$(shell $(TOPDIR)/tools/setlocalversion $(TOPDIR))' ) $@.tmp + @( printf '#define CC_VERSION_STRING %s\n' \ +'$(shell $(CC) --version | head -1)' ) $@.tmp @cmp -s $@ $@.tmp rm -f $@.tmp || mv -f $@.tmp $@ $(TIMESTAMP_FILE): Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] ARM: print gcc version
Am 18.01.2011 17:20, schrieb Peter Tyser: Anyway, I would found it a nice feature, at startup or when running the version command, but both aren't a must. I think it would be a really useful extension to the version command. Looking forwad to seeing your patch. Maybe if someone could feed me with what to use for the version. E.g. my gcc here defines __VERSION__ as 4.5.2 but when I'm looking at u-boot/lib/asm-offsets.s I see .ident GCC: (Gentoo 4.5.2 p1.0, pie-0.4.5) 4.5.2 So I would like to display that which would be in line with the comment section of generated binaries. But when I use gcc -E -dM empty.c to print all predefined macros, I don't see the text found in .ident. Not even something else which includes Gentoo. I believe the output of $(CC) --version should contain the same data as your .ident string. You could echo it into a file like: diff --git a/Makefile b/Makefile index 0685ef9..e070d40 100644 --- a/Makefile +++ b/Makefile @@ -416,6 +416,8 @@ $(U_BOOT_ONENAND): $(ONENAND_IPL) $(obj)u-boot.bin $(VERSION_FILE): @( printf '#define U_BOOT_VERSION U-Boot %s%s\n' $(U_BOOT_VERSION) \ '$(shell $(TOPDIR)/tools/setlocalversion $(TOPDIR))' ) $@.tmp + @( printf '#define CC_VERSION_STRING %s\n' \ +'$(shell $(CC) --version | head -1)' ) $@.tmp @cmp -s $@ $@.tmp rm -f $@.tmp || mv -f $@.tmp $@ $(TIMESTAMP_FILE): That would the trick. The first line of gcc --version includes here the correct string. Thanks. (Btw. I would use head -n 1) But I will wait for a comment from one of the maintainers about defining CC_VERSION_STRING. If someone gives me an ok, I will write a patch including your suggestion and will print that version in the command version. Regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] altera_spi: add spi_set_speed
Added to: git://git.denx.de/u-boot-nios.git 'next'
Thank you,
--Scott
Thomas Chou wrote:
Added this for mmc_spi driver. Though altera spi core does not
support programmable speed. It is fixed when configured in
sopc-builder.
Signed-off-by: Thomas Chou tho...@wytron.com.tw
---
drivers/spi/altera_spi.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/spi/altera_spi.c b/drivers/spi/altera_spi.c
index 918b223..138d6f4 100644
--- a/drivers/spi/altera_spi.c
+++ b/drivers/spi/altera_spi.c
@@ -70,6 +70,11 @@ void spi_init(void)
{
}
+void spi_set_speed(struct spi_slave *slave, uint hz)
+{
+ /* altera spi core does not support programmable speed */
+}
+
struct spi_slave *spi_setup_slave(unsigned int bus, unsigned int cs,
unsigned int max_hz, unsigned int mode)
{
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] nios2: use long for ssize_t
Added to: git://git.denx.de/u-boot-nios.git 'next' Thank you, --Scott Thomas Chou wrote: This is consistent with nios2-linux. And resolved the warning, cmd_nvedit.c: In function `do_env_export': cmd_nvedit.c:660: warning: size_t format, ssize_t arg (arg 3) Signed-off-by: Thomas Chou tho...@wytron.com.tw --- arch/nios2/include/asm/posix_types.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/nios2/include/asm/posix_types.h b/arch/nios2/include/asm/posix_types.h index c2deea6..6733640 100644 --- a/arch/nios2/include/asm/posix_types.h +++ b/arch/nios2/include/asm/posix_types.h @@ -17,7 +17,7 @@ typedef unsigned short __kernel_ipc_pid_t; typedef unsigned short __kernel_uid_t; typedef unsigned short __kernel_gid_t; typedef unsigned long__kernel_size_t; -typedef int __kernel_ssize_t; +typedef long __kernel_ssize_t; typedef int __kernel_ptrdiff_t; typedef long __kernel_time_t; typedef long __kernel_suseconds_t; ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] nios2: add gpio_is_valid
Added to: git://git.denx.de/u-boot-nios.git 'next'
Thank you,
--Scott
Thomas Chou wrote:
Signed-off-by: Thomas Chou tho...@wytron.com.tw
---
arch/nios2/include/asm/gpio.h|6 ++
board/altera/nios2-generic/custom_fpga.h |1 +
board/altera/nios2-generic/gpio.c|6 ++
3 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/arch/nios2/include/asm/gpio.h b/arch/nios2/include/asm/gpio.h
index 36a7132..4b21c8f 100644
--- a/arch/nios2/include/asm/gpio.h
+++ b/arch/nios2/include/asm/gpio.h
@@ -52,6 +52,11 @@ static inline void gpio_set_value(unsigned gpio, int value)
{
writel(value ? 3 : 2, CONFIG_SYS_GPIO_BASE + (gpio 2));
}
+
+static inline int gpio_is_valid(int number)
+{
+ return ((unsigned)number) CONFIG_SYS_GPIO_WIDTH;
+}
#else
extern int gpio_request(unsigned gpio, const char *label);
extern int gpio_free(unsigned gpio);
@@ -59,6 +64,7 @@ extern int gpio_direction_input(unsigned gpio);
extern int gpio_direction_output(unsigned gpio, int value);
extern int gpio_get_value(unsigned gpio);
extern void gpio_set_value(unsigned gpio, int value);
+extern int gpio_is_valid(int number);
#endif /* CONFIG_SYS_GPIO_BASE */
#endif /* _ASM_NIOS2_GPIO_H_ */
diff --git a/board/altera/nios2-generic/custom_fpga.h
b/board/altera/nios2-generic/custom_fpga.h
index a11add5..f7f3853 100644
--- a/board/altera/nios2-generic/custom_fpga.h
+++ b/board/altera/nios2-generic/custom_fpga.h
@@ -50,6 +50,7 @@
/* led_pio.s1 is a altera_avalon_pio */
#define LED_PIO_BASE 0x82120870
+#define LED_PIO_WIDTH 8
/* high_res_timer.s1 is a altera_avalon_timer */
#define CONFIG_SYS_TIMER_BASE 0x82120820
diff --git a/board/altera/nios2-generic/gpio.c
b/board/altera/nios2-generic/gpio.c
index 8c639ce..4a30564 100644
--- a/board/altera/nios2-generic/gpio.c
+++ b/board/altera/nios2-generic/gpio.c
@@ -10,6 +10,7 @@
#ifndef CONFIG_SYS_GPIO_BASE
#define ALTERA_PIO_BASE LED_PIO_BASE
+#define ALTERA_PIO_WIDTH LED_PIO_WIDTH
#define ALTERA_PIO_DATA (ALTERA_PIO_BASE + 0)
#define ALTERA_PIO_DIR (ALTERA_PIO_BASE + 4)
static u32 pio_data_reg;
@@ -62,4 +63,9 @@ void gpio_set_value(unsigned gpio, int value)
pio_data_reg = ~mask;
writel(pio_data_reg, ALTERA_PIO_DATA);
}
+
+int gpio_is_valid(int number)
+{
+ return ((unsigned)number) ALTERA_PIO_WIDTH;
+}
#endif
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] nios2: add gpio_free
Added to: git://git.denx.de/u-boot-nios.git 'next'
Thank you,
--Scott
Thomas Chou wrote:
Signed-off-by: Thomas Chou tho...@wytron.com.tw
---
arch/nios2/include/asm/gpio.h |6 ++
board/altera/nios2-generic/gpio.c |5 +
2 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/nios2/include/asm/gpio.h b/arch/nios2/include/asm/gpio.h
index cff1dd9..36a7132 100644
--- a/arch/nios2/include/asm/gpio.h
+++ b/arch/nios2/include/asm/gpio.h
@@ -26,6 +26,11 @@ static inline int gpio_request(unsigned gpio, const char
*label)
return 0;
}
+static inline int gpio_free(unsigned gpio)
+{
+ return 0;
+}
+
static inline int gpio_direction_input(unsigned gpio)
{
writel(1, CONFIG_SYS_GPIO_BASE + (gpio 2));
@@ -49,6 +54,7 @@ static inline void gpio_set_value(unsigned gpio, int value)
}
#else
extern int gpio_request(unsigned gpio, const char *label);
+extern int gpio_free(unsigned gpio);
extern int gpio_direction_input(unsigned gpio);
extern int gpio_direction_output(unsigned gpio, int value);
extern int gpio_get_value(unsigned gpio);
diff --git a/board/altera/nios2-generic/gpio.c
b/board/altera/nios2-generic/gpio.c
index d449684..8c639ce 100644
--- a/board/altera/nios2-generic/gpio.c
+++ b/board/altera/nios2-generic/gpio.c
@@ -20,6 +20,11 @@ int gpio_request(unsigned gpio, const char *label)
return 0;
}
+int gpio_free(unsigned gpio)
+{
+ return 0;
+}
+
int gpio_direction_input(unsigned gpio)
{
u32 mask = 1 gpio;
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] powerpc: Add LINK_OFF calls in early C-code.
On Tue, 18 Jan 2011 01:18:34 +0100 Joakim Tjernlund joakim.tjernl...@transmode.se wrote: How do you think a solution for all boards would look like? The only other method is can think of is some MMU trickery and I don't even see how you can make that work on all boards and You don't need to make the MMU trick work on all boards, just your board (or cpu family), because it wouldn't be imposing anything on the rest of the system. Do we actually have someone who needs this feature on a board without a suitable MMU, large lockable cache or other SRAM, hardware bank switching, or other mechanism that can be confined to early low-level board/cpu-specific code? you would probably be locked to specific address ranges if you use BATs as defined on PowerPC You'd have alignment constraints, but it's good enough for bank switching. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] MC13892: Add SWx buck switchers definitions
Define voltages configurable on SWx buck switchers. Signed-off-by: Marek Vasut marek.va...@gmail.com --- include/mc13892.h | 35 +++ 1 files changed, 35 insertions(+), 0 deletions(-) diff --git a/include/mc13892.h b/include/mc13892.h index 61c3e6e..6d86e55 100644 --- a/include/mc13892.h +++ b/include/mc13892.h @@ -160,4 +160,39 @@ /* Reg Power Control 2*/ #define WDIRESET (1 12) +/* Buck Switchers (SW1,2,3,4) Output Voltage */ +#define SWx_0_600V 0 +#define SWx_0_625V 1 +#define SWx_0_650V 2 +#define SWx_0_675V 3 +#define SWx_0_700V 4 +#define SWx_0_725V 5 +#define SWx_0_750V 6 +#define SWx_0_775V 7 +#define SWx_0_800V 8 +#define SWx_0_825V 9 +#define SWx_0_850V 10 +#define SWx_0_875V 11 +#define SWx_0_900V 12 +#define SWx_0_925V 13 +#define SWx_0_950V 14 +#define SWx_0_975V 15 +#define SWx_1_000V 16 +#define SWx_1_025V 17 +#define SWx_1_050V 18 +#define SWx_1_075V 19 +#define SWx_1_100V 20 +#define SWx_1_125V 21 +#define SWx_1_150V 22 +#define SWx_1_175V 23 +#define SWx_1_200V 24 +#define SWx_1_225V 25 +#define SWx_1_250V 26 +#define SWx_1_275V 27 +#define SWx_1_300V 28 +#define SWx_1_325V 29 +#define SWx_1_350V 30 +#define SWx_1_375V 31 +#define SWx_VOLT_MASK 0x1F + #endif -- 1.7.2.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] MX51EVK: Use SWx macros in PMIC init
Signed-off-by: Marek Vasut marek.va...@gmail.com --- board/freescale/mx51evk/mx51evk.c |7 --- 1 files changed, 4 insertions(+), 3 deletions(-) diff --git a/board/freescale/mx51evk/mx51evk.c b/board/freescale/mx51evk/mx51evk.c index 2160d5a..bcf1934 100644 --- a/board/freescale/mx51evk/mx51evk.c +++ b/board/freescale/mx51evk/mx51evk.c @@ -198,17 +198,18 @@ static void power_init(void) /* Set core voltage to 1.1V */ val = pmic_reg_read(REG_SW_0); - val = (val (~0x1F)) | 0x14; + val = (val (~SWx_VOLT_MASK)) | SWx_1_100V; pmic_reg_write(REG_SW_0, val); /* Setup VCC (SW2) to 1.25 */ val = pmic_reg_read(REG_SW_1); - val = (val (~0x1F)) | 0x1A; + val = (val (~SWx_VOLT_MASK)) | SWx_1_250V; + pmic_reg_write(REG_SW_1, val); /* Setup 1V2_DIG1 (SW3) to 1.25 */ val = pmic_reg_read(REG_SW_2); - val = (val (~0x1F)) | 0x1A; + val = (val (~SWx_VOLT_MASK)) | SWx_1_250V; pmic_reg_write(REG_SW_2, val); udelay(50); -- 1.7.2.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3 v3] iMX5: EfikaMX: Preliminary board support
Supported: MMC IDE PMIC SPI flash LEDs I can boot the kernel supplied by freescale/genesi with this from MMC card and/or PATA disk. Signed-off-by: Marek Vasut marek.va...@gmail.com --- v3: Use SWx definitions as proposed by Stefano MAINTAINERS|1 + board/efikamx/Makefile | 52 board/efikamx/config.mk| 25 ++ board/efikamx/efikamx.c| 695 board/efikamx/imximage.cfg | 122 boards.cfg |1 + include/configs/efikamx.h | 232 +++ 7 files changed, 1128 insertions(+), 0 deletions(-) create mode 100644 board/efikamx/Makefile create mode 100644 board/efikamx/config.mk create mode 100644 board/efikamx/efikamx.c create mode 100644 board/efikamx/imximage.cfg create mode 100644 include/configs/efikamx.h diff --git a/MAINTAINERS b/MAINTAINERS index a799037..8f1b1b6 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -823,6 +823,7 @@ Marek Vasut marek.va...@gmail.com palmtc xscale vpac270 xscale zipitz2 xscale + efikamx i.MX51 Hugo Villeneuve hugo.villene...@lyrtech.com diff --git a/board/efikamx/Makefile b/board/efikamx/Makefile new file mode 100644 index 000..ee4a16e --- /dev/null +++ b/board/efikamx/Makefile @@ -0,0 +1,52 @@ +# +# Copyright (C) 2010, Marek Vasut marek.va...@gmail.com +# +# BASED ON: imx51evk +# +# Copyright (C) 2007, Guennadi Liakhovetski l...@denx.de +# +# (C) Copyright 2009 Freescale Semiconductor, Inc. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# 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).o + +COBJS := efikamx.o + +SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS)) +SOBJS := $(addprefix $(obj),$(SOBJS)) + +$(LIB):$(obj).depend $(OBJS) $(SOBJS) + $(call cmd_link_o_target, $(OBJS) $(SOBJS)) + +clean: + rm -f $(SOBJS) $(OBJS) + +distclean: clean + rm -f $(LIB) core *.bak .depend + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/board/efikamx/config.mk b/board/efikamx/config.mk new file mode 100644 index 000..6e90671 --- /dev/null +++ b/board/efikamx/config.mk @@ -0,0 +1,25 @@ +# +# Copyright 2009 Freescale Semiconductor, Inc. All Rights Reserved. +# +# 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 +# + +CONFIG_SYS_TEXT_BASE = 0x9780 +IMX_CONFIG = $(SRCTREE)/board/$(BOARDDIR)/imximage.cfg +ALL += $(obj)u-boot.imx diff --git a/board/efikamx/efikamx.c b/board/efikamx/efikamx.c new file mode 100644 index 000..cd919e4 --- /dev/null +++ b/board/efikamx/efikamx.c @@ -0,0 +1,695 @@ +/* + * Copyright (C) 2010 Marek Vasut marek.va...@gmail.com + * + * (C) Copyright 2009 Freescale Semiconductor, Inc. + * + * 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
Re: [U-Boot] [PATCH 2/2] iMX5: EfikaMX: Work-in-progress board support
On Thursday 13 January 2011 18:46:02 Stefano Babic wrote: On 01/13/2011 06:15 PM, Marek Vasut wrote: + mxc_request_iomux(MX51_PIN_NANDF_RB3, IOMUX_CONFIG_GPIO); + mxc_iomux_set_pad(MX51_PIN_NANDF_RB3, PAD_CTL_100K_PU); + mxc_gpio_direction(IOMUX_TO_GPIO(MX51_PIN_NANDF_RB3), MXC_GPIO_DIRECTION_IN); + rev |= (!!mxc_gpio_get(IOMUX_TO_GPIO(MX51_PIN_NANDF_RB3))) 2; Is it ok to leave the NAND pins configured as GPIO, or should they set back for the NFC controller ? I don't think there is even NAND used on efikamx. Though I might be mistaken. Understood, then I agree to leave the iomux set with gpios. Replace fix constants with defines, adding them to mc13892.h if they are missing. Is any sane datasheet for this thing available ? If so, can you link me to it please? There is a datasheet, I do not know if you can consider it sane ;-) http://cache.freescale.com/files/analog/doc/data_sheet/MC13892.pdf?fpsp=1 The register description is quite spread in the manual. You can see the complete SPI Bitmap on pages 118-121. I have already set most constants in include/mc13892.h, probably there are some missing. +#define __io I think we have already discussed abot this define. Should it not move to another file, such as imx-regs.h ? Or is there a better solution ? The thread where we discussed this got deaf. I tried asking further, but no reply :-( Agree, I remember the issue, I do not remember any decision. Anyway, I think the position of this macro is wrong. It is related to the processor, that can have it or not, and it is not related to the board. I see that in u-boot __io is defined in board configuration file, but I do not think it is correct. At least I will suggest to move this define in the processor related file (--imx-regs.h). This is a problem, if __io is defined there, it won't be defined in the ide driver. Cheers, Stefano ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] iMX5: EfikaMX: Preliminary board support
On Sunday 16 January 2011 16:21:34 Stefano Babic wrote: On 01/13/2011 06:27 PM, Marek Vasut wrote: As for the PMIC, other boards don't use any #defines for those constants either, which obviously doens't mean it's right. Well, this is not true. You use in yourd board a lot of these constants. There are only a few of them that are not used and + + /* NOTE: if (is_soc_rev(CHIP_REV_2_0) = 0) */ You can drop this line + + /* Set core voltage to 1.1V */ + val = pmic_reg_read(REG_SW_0); + val = (val (~0x1F)) | 0x14; + pmic_reg_write(REG_SW_0, val); Values are defined in Table 47 in MC13892.h manual. The low level is 0.6 Volt, that corresponds to 0x0, and each bit increments the voltage by 25mV. I can suggest to add a macro to mc13892.h that return the value for register when the desired voltage (in millivolt) is passed. + + /* Setup VCC (SW2) to 1.25 */ + val = pmic_reg_read(REG_SW_1); + val = (val (~0x1F)) | 0x1A; + pmic_reg_write(REG_SW_1, val); ..and use it here, too. + + /* Setup 1V2_DIG1 (SW3) to 1.25 */ + val = pmic_reg_read(REG_SW_2); + val = (val (~0x1F)) | 0x1A; + pmic_reg_write(REG_SW_2, val); + udelay(50); ..and here. Fixed +/*** *** I have not checked before, but this is not the coding style for multiline comments. Well it's more of a section separator, that's why this bold stuff. I'd prefer to leave it there for readability's sake. Cheers ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] powerpc: Add LINK_OFF calls in early C-code.
Scott Wood scottw...@freescale.com wrote on 2011/01/18 18:27:49: On Tue, 18 Jan 2011 01:18:34 +0100 Joakim Tjernlund joakim.tjernl...@transmode.se wrote: How do you think a solution for all boards would look like? The only other method is can think of is some MMU trickery and I don't even see how you can make that work on all boards and You don't need to make the MMU trick work on all boards, just your board (or cpu family), because it wouldn't be imposing anything on the rest of the system. Do we actually have someone who needs this feature on a board without a suitable MMU, large lockable cache or other SRAM, hardware bank switching, or other mechanism that can be confined to early low-level board/cpu-specific code? Wolfgang seems to think so. As I read his reply he wants a solution for all boards which I don't think is possible. I do think my approach comes closest though. I did try BATs but I didn't get very far. you would probably be locked to specific address ranges if you use BATs as defined on PowerPC You'd have alignment constraints, but it's good enough for bank switching. Alignment and a suitable bank size so you don't fall into your environment. That may make BATs hard to use in general. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 7/8] imximage: Add MX53 boot image support
Dear Jason Liu,
In message aanlktiny2u9cvfwjurnmoewazqxlceyqlpw__dgup...@mail.gmail.com you
wrote:
...
static table_entry_t imximage_cmds[] = {
+ {CMD_IMAGE_VERSION, IMAGE_VERSION,i mage version, },
{CMD_BOOT_FROM, BOOT_FROM, boot command, },
{CMD_DATA, DATA, Reg Write Data,
},
{-1,, , },
Can we please keep the table sorted?
what does the keep the table sorted mean?
Sorted means that the entries should be sorted, and sort order is B,
D, I.
I think this function does not need return something, I will fix as
following, is it OK,
static void set_dcd_rst_v1(struct imx_header *imxhdr, uint32_t dcd_len,
char *name, int lineno)
{
dcd_v1_t *dcd_v1 = imxhdr-header.hdr_v1.dcd_table;
if (dcd_len MAX_HW_CFG_SIZE_V1) {
fprintf(stderr, Error: %s[%d] -
DCD table exceeds maximum size(%d)\n,
name, lineno, MAX_HW_CFG_SIZE_V1);
+ exit(EXIT_FAILURE);
}
That's fine with 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
There is nothing new under the sun, but there are lots of old things
we don't know yet. - Ambrose Bierce
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Coding Style question
Dear Kumar Gala, In message 3d755410-9073-43de-b772-d5649ed96...@kernel.crashing.org you wrote: In a header define register fields we have something like: +#define CSOR_NAND_TRHZ_MASK0x001C /* Time for Read Enable + High to Output High + Impedance */ Is this multiple line comment style ok - since we are dealing with line wrap ? I dislike it, and always try hard to avoind things like this. It would probably better to write instead /* Time for Read Enable High to Output High Impedance */ #define CSOR_NAND_TRHZ_MASK 0x001C Note that I have even seen compilers (some time ago, admitted) where such code would cause build errors (that version of the compiler would 1) insert 0x001C /* Time for Read Enable for CSOR_NAND_TRHZ_MASK and 2) barf loudly about a lot of unterminated and one un-opened comments). Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I'm frequently appalled by the low regard you Earthmen have for life. -- Spock, The Galileo Seven, stardate 2822.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] ARM: print gcc version
Dear Alexander Holler, In message 4d35c836.3020...@ahsoftware.de you wrote: @@ -416,6 +416,8 @@ $(U_BOOT_ONENAND): $(ONENAND_IPL) $(obj)u-boot.bin $(VERSION_FILE): @( printf '#define U_BOOT_VERSION U-Boot %s%s\n' $(U_BOOT_VERSION) \ '$(shell $(TOPDIR)/tools/setlocalversion $(TOPDIR))' ) $@.tmp + @( printf '#define CC_VERSION_STRING %s\n' \ +'$(shell $(CC) --version | head -1)' ) $@.tmp @cmp -s $@ $@.tmp rm -f $@.tmp || mv -f $@.tmp $@ $(TIMESTAMP_FILE): That would the trick. The first line of gcc --version includes here the correct string. Thanks. (Btw. I would use head -n 1) But I will wait for a comment from one of the maintainers about defining CC_VERSION_STRING. If someone gives me an ok, I will write a patch including your suggestion and will print that version in the command version. Looks good to me - please go on. Hm... while we are at it... the bintuils (especially linker) version is probably equally interesting, so eventually we should also add a LD_VERSION_STRING. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de A right is not what someone gives you; it's what no one can take from you. - Ramsey Clark ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] powerpc: Add LINK_OFF calls in early C-code.
Dear Joakim Tjernlund, In message of287114d8.013b6e51-onc125781c.00667dcd-c125781c.00673...@transmode.se you wrote: You don't need to make the MMU trick work on all boards, just your board (or cpu family), because it wouldn't be imposing anything on the rest of the system. Do we actually have someone who needs this feature on a board without a suitable MMU, large lockable cache or other SRAM, hardware bank switching, or other mechanism that can be confined to early low-level board/cpu-specific code? Wolfgang seems to think so. As I read his reply he wants a solution for all Please be aware that I don't think anything at all. I just comment :-) I'm not in your position, where I am focussing on how can I implement this. I'm looking at the code from the outside, and I ask what does it give to me, what of the things I'd like to have does it not give to me, and at which price does it come. boards which I don't think is possible. I do think my approach comes closest though. I did try BATs but I didn't get very far. If we are talking about _all_ boards we have to keep a wider view. For example, on MPC8xx there are not BATs. Not to mention other architectures. Actually I was not asking for support for all boards, not even for all boards of a specific architecture, or a specific CPU. You submitted this patch, and I learned that the code, as is, is only useful for a single board, which appears to be maintained in an out-of-tree port. For all in-tree boards the code, as is, is broken and unusable without further rework. Needless to repeat that it is completely untested for mainline. So we have a patch that promises a feature, which cannot be used by any of the mainline boards, but it makes the code more complex for zero benefit. It's a nice and appreciated RFC patch or even example implementation, but I fail to see arguments why we should add this to mainline. 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 In the future, you're going to get computers as prizes in breakfast cereals. You'll throw them out because your house will be littered with them. - Robert Lucky ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] iMX5: EfikaMX: Preliminary board support
Dear Marek Vasut, In message 201101182032.33444.marek.va...@gmail.com you wrote: +/*** *** I have not checked before, but this is not the coding style for multiline comments. Well it's more of a section separator, that's why this bold stuff. I'd prefer to leave it there for readability's sake. Please fix it. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de They weren't that important. They were merely at the top. The people who really run organizations are usually found several levels down, where it's still possible to get things done. - Terry Pratchett, _Small Gods_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] powerpc: Add LINK_OFF calls in early C-code.
On Tue, 18 Jan 2011 21:06:34 +0100 Wolfgang Denk w...@denx.de wrote: Dear Joakim Tjernlund, In message of287114d8.013b6e51-onc125781c.00667dcd-c125781c.00673...@transmode.se you wrote: boards which I don't think is possible. I do think my approach comes closest though. I did try BATs but I didn't get very far. What problems did you run into? If we are talking about _all_ boards we have to keep a wider view. For example, on MPC8xx there are not BATs. Not to mention other architectures. I don't see why MPC8xx's MMU couldn't be used for this, although it might be a tight fit if you want to get everything into the pinned TLB entries. Should we be talking about all boards, if the only user of this so far is on hardware that can do it in a less-intrusive way? Another thing to keep in mind is that Joakim's approach also won't work on all boards -- you need hardware that is capable of selecting from different entry points, where the entry address itself changes rather than flash banks being flipped around. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] powerpc: Add LINK_OFF calls in early C-code.
Scott Wood scottw...@freescale.com wrote on 2011/01/18 21:24:16: On Tue, 18 Jan 2011 21:06:34 +0100 Wolfgang Denk w...@denx.de wrote: Dear Joakim Tjernlund, In message of287114d8.013b6e51-onc125781c.00667dcd-c125781c.00673...@transmode.se you wrote: boards which I don't think is possible. I do think my approach comes closest though. I did try BATs but I didn't get very far. What problems did you run into? It crashed and burned :) I never got to the details. If we are talking about _all_ boards we have to keep a wider view. For example, on MPC8xx there are not BATs. Not to mention other architectures. I don't see why MPC8xx's MMU couldn't be used for this, although it might be a tight fit if you want to get everything into the pinned TLB entries. I think it is harder that that. You probably need a tlb miss handler. Should we be talking about all boards, if the only user of this so far is on hardware that can do it in a less-intrusive way? Another thing to keep in mind is that Joakim's approach also won't work on all boards -- you need hardware that is capable of selecting from different entry points, where the entry address itself changes rather than flash banks being flipped around. No, you only need gcc support for msingle-pic-base and some extra RAM to hold the GOT(about 8KB would do I think) while still in flash. Ah, you mean how to select which image to select? That is a small piece of SW that checks both images and chooses the valid one and jumps there. Jocke ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 1/1] imximage: Add MX53 boot image support
This patch add the MX53 boot image support.
This patch has been tested on Freescale MX53EVK board
and MX51EVK board.
Signed-off-by: Jason Liu r64...@freescale.com
---
Changes for v2:
- Address the following comments from Stefano,
- Get rid of #ifdef in the imximage.h and .c file and use
the runtime check for imximage version
- Document the IMXIMAGE_VERSION definiton in doc/README.imximage
- Move mx53evk/config.mk and mx53evk/imximage.cfg to MX53EVK board
support patch.
Changes for v3:
- Address the following comments from Stefano,
- Not change the mx51evk file. The code should take VERSION=1 as default,
and we do not need to change the actual boards.
- add a note in the documentation and raise an error in code if the
VERSION command is read after any other suitable commands.
- Change command IMXIMAGE_VERSION simply to IMAGE_VERSION
- Need recognize the version directly from its structure and not storing the
version into the header when do header verify and print.
- Use function pointer to simpliy the code when the version of header is
recognized
Changes for v4:
- Address the following comments from Wolfgang,
- Keep the imximage_cmds table sorted,
- Add braces for (expx) (expy) gloably,
- Return failure to upper call if met errors for function
- Add comments for function set_dcd_rst_v1 alike,
- Re-orgnize code to avoid deep nesting,
---
doc/README.imximage | 12 +-
tools/imximage.c| 527 +--
tools/imximage.h| 110 +--
3 files changed, 489 insertions(+), 160 deletions(-)
diff --git a/doc/README.imximage b/doc/README.imximage
index 3378f7e..c74239d 100644
--- a/doc/README.imximage
+++ b/doc/README.imximage
@@ -57,6 +57,13 @@ Configuration command line syntax:
2. Following are the valid command strings and associated data strings:-
Command string data string
-- ---
+ IMXIMAGE_VERSION1/2
+ 1 is for mx25/mx35/mx51 compatible,
+ 2 is for mx53 compatible,
+ others is invalid and error is generated.
+ This command need appear the fist before
+ other valid commands in configuration file.
+
BOOT_FROM nand/spi/sd/onenand
Example:
BOOT_FROM spi
@@ -69,8 +76,9 @@ Configuration command line syntax:
Example (write to IOMUXC):
DATA 4 0x73FA88a0 0x200
-The processor support up to 60 register programming commands. An error
-is generated if more commands are found in the configuration file.
+The processor support up to 60 register programming commands for
IMXIMAGE_VERSION 1
+and 121 register programming commands for IMXIMAGE_VERSION 2.
+An error is generated if more commands are found in the configuration file.
3. All commands are optional to program.
diff --git a/tools/imximage.c b/tools/imximage.c
index 39f89c2..dcfcbd5 100644
--- a/tools/imximage.c
+++ b/tools/imximage.c
@@ -36,9 +36,10 @@
* Supported commands for configuration file
*/
static table_entry_t imximage_cmds[] = {
- {CMD_BOOT_FROM, BOOT_FROM,boot command, },
- {CMD_DATA, DATA, Reg Write Data, },
- {-1,, , },
+ {CMD_BOOT_FROM, BOOT_FROM,boot command, },
+ {CMD_DATA, DATA, Reg Write Data, },
+ {CMD_IMAGE_VERSION, IMAGE_VERSION,image version, },
+ {-1,, , },
};
/*
@@ -53,8 +54,21 @@ static table_entry_t imximage_bootops[] = {
{-1,, Invalid, },
};
+/*
+ * IMXIMAGE version definition for i.MX chips
+ */
+static table_entry_t imximage_versions[] = {
+ {IMXIMAGE_V1, , (i.MX25/35/51 compatible), },
+ {IMXIMAGE_V2, , (i.MX53 compatible), },
+ {-1,, (Invalid), },
+};
static struct imx_header imximage_header;
+static uint32_t imximage_version;
+
+static set_dcd_val_t set_dcd_val;
+static set_dcd_rst_t set_dcd_rst;
+static set_imx_hdr_t set_imx_hdr;
static uint32_t get_cfg_value(char *token, char *name, int linenr)
{
@@ -71,67 +85,355 @@ static uint32_t get_cfg_value(char *token, char *name,
int linenr)
return value;
}
-static int imximage_check_image_types(uint8_t type)
+static uint32_t detect_imximage_version(struct imx_header *imx_hdr)
{
- if (type == IH_TYPE_IMXIMAGE)
- return EXIT_SUCCESS;
- else
- return EXIT_FAILURE;
+ imx_header_v1_t *hdr_v1 = imx_hdr-header.hdr_v1;
+ imx_header_v2_t *hdr_v2 = imx_hdr-header.hdr_v2;
+ flash_header_v1_t
Re: [U-Boot] [PATCH 1/3] MC13892: Add SWx buck switchers definitions
Hi, Marek, 2011/1/19 Marek Vasut marek.va...@gmail.com: Define voltages configurable on SWx buck switchers. Signed-off-by: Marek Vasut marek.va...@gmail.com --- include/mc13892.h | 35 +++ 1 files changed, 35 insertions(+), 0 deletions(-) diff --git a/include/mc13892.h b/include/mc13892.h index 61c3e6e..6d86e55 100644 --- a/include/mc13892.h +++ b/include/mc13892.h @@ -160,4 +160,39 @@ /* Reg Power Control 2*/ #define WDIRESET (1 12) +/* Buck Switchers (SW1,2,3,4) Output Voltage */ +#define SWx_0_600V 0 +#define SWx_0_625V 1 +#define SWx_0_650V 2 +#define SWx_0_675V 3 +#define SWx_0_700V 4 +#define SWx_0_725V 5 +#define SWx_0_750V 6 +#define SWx_0_775V 7 +#define SWx_0_800V 8 +#define SWx_0_825V 9 +#define SWx_0_850V 10 +#define SWx_0_875V 11 +#define SWx_0_900V 12 +#define SWx_0_925V 13 +#define SWx_0_950V 14 +#define SWx_0_975V 15 +#define SWx_1_000V 16 +#define SWx_1_025V 17 +#define SWx_1_050V 18 +#define SWx_1_075V 19 +#define SWx_1_100V 20 +#define SWx_1_125V 21 +#define SWx_1_150V 22 +#define SWx_1_175V 23 +#define SWx_1_200V 24 +#define SWx_1_225V 25 +#define SWx_1_250V 26 +#define SWx_1_275V 27 +#define SWx_1_300V 28 +#define SWx_1_325V 29 +#define SWx_1_350V 30 +#define SWx_1_375V 31 +#define SWx_VOLT_MASK 0x1F This definition is for SWxHI=0 (Volts), had better state it in the comments, + #endif -- 1.7.2.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] powerpc: Add LINK_OFF calls in early C-code.
Wolfgang Denk w...@denx.de wrote on 2011/01/18 21:06:34: Dear Joakim Tjernlund, In message of287114d8.013b6e51-onc125781c.00667dcd-c125781c.00673...@transmode.se you wrote: You don't need to make the MMU trick work on all boards, just your board (or cpu family), because it wouldn't be imposing anything on the rest of the system. Do we actually have someone who needs this feature on a board without a suitable MMU, large lockable cache or other SRAM, hardware bank switching, or other mechanism that can be confined to early low-level board/cpu-specific code? Wolfgang seems to think so. As I read his reply he wants a solution for all Please be aware that I don't think anything at all. I just comment :-) I'm not in your position, where I am focussing on how can I implement this. I'm looking at the code from the outside, and I ask what does it give to me, what of the things I'd like to have does it not give to me, and at which price does it come. boards which I don't think is possible. I do think my approach comes closest though. I did try BATs but I didn't get very far. If we are talking about _all_ boards we have to keep a wider view. For example, on MPC8xx there are not BATs. Not to mention other architectures. Actually I was not asking for support for all boards, not even for all boards of a specific architecture, or a specific CPU. You submitted this patch, and I learned that the code, as is, is only useful for a single board, which appears to be maintained in an out-of-tree port. For all in-tree boards the code, as is, is broken and unusable without further rework. Needless to repeat that it is completely untested for mainline. Ah, finally you make sense to me. I actually tested this with mainline on my board so it is not completely untested in mainline. So we have a patch that promises a feature, which cannot be used by any of the mainline boards, but it makes the code more complex for zero benefit. You can test that nothing breaks in other 83xx boards. That would be valuable feedback to me. I can try to complete all NOR based 83xx boards too, but someone needs to test them. It's a nice and appreciated RFC patch or even example implementation, but I fail to see arguments why we should add this to mainline. Well, you have to start somewhere and as this involves asm changes in start.S it would be pretty dangerous add these without being able to test. The idea is that once some version of this patch is in, interested parties can apply the same concept on their boards too. Finally, I would like to remind you about [PATCH] PowerPC: Move -fPIC flag to common place [PATCH] PowerPC: Add support for -msingle-pic-base Those two stands on its own. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] NetRxPackets
On Tuesday, January 18, 2011 01:15:25 am Marcel wrote: Hi, ether.c contains the following code : req-buf = (u8 *) NetRxPackets[0]; req-length = size; req-complete = rx_complete; retval = usb_ep_queue(dev-out_ep, req, gfp_flags); My USB controller code that I'm writing responds that req-buf is NULL. So the OUT packets don't get processed. I know OUT data arrives in my controller code as I can read it, so my OUT endpoint is working. Also my status endpoint is working correctly and my guess is there's nothing wrong with my controller code. Anyone have an idea how NetRxPackets is allocated ? Nobody ? req-buf = (u8 *) NetRxPackets[0]; This is returning an non existing buffer for some reason and I know not much about the ethernet layer to fix this. My guess is I miss some define (eth related) somewhere but I'm also about to give up on ether.c and just port a more simple driver to u-boot for testing USB device controller drivers. Any ideas why this could happen or how I can find out why that is ? Best regards, Marcel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] powerpc: Add LINK_OFF calls in early C-code.
Dear Scott Wood, In message 20110118142416.5892c...@udp111988uds.am.freescale.net you wrote: If we are talking about _all_ boards we have to keep a wider view. For example, on MPC8xx there are not BATs. Not to mention other architectures. I don't see why MPC8xx's MMU couldn't be used for this, although it might be a tight fit if you want to get everything into the pinned TLB entries. I just wanted to point out that the use BATs then approach is also not a solution that covers all systems. Should we be talking about all boards, if the only user of this so far is on hardware that can do it in a less-intrusive way? In the first round of discussion the buzz word was to acchieve a fully position independent U-Boot image. This would obviously have a number of nice use cases, including the often asked for load test version to free area in RAM and jump to it. This is somehting that would indeed be useful for all boards, on all architectures, all SoCs. So it makes sense to me to include into the reviewing if a proposed solution is capable of being generalized to other boards / systems or not. Another thing to keep in mind is that Joakim's approach also won't work on all boards -- you need hardware that is capable of selecting from different entry points, where the entry address itself changes rather than flash banks being flipped around. There could be other mechanisms in place to determine which U-Boot image should be started, like a tiny piece of software that jumps to the selected image. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Unsichtbar macht sich die Dummheit, indem sie immer größere Ausmaße annimmt. -- Bertold Brecht: Der Tui-Roman ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] powerpc: Add LINK_OFF calls in early C-code.
Dear Joakim Tjernlund, In message ofbbe91305.b19350d9-onc125781c.007192fc-c125781c.00742...@transmode.se you wrote: Ah, finally you make sense to me. I actually tested this with mainline on my board so it is not completely untested in mainline. As your board itself is not in mainline this _is_ completely untested for mainline. It's a nice and appreciated RFC patch or even example implementation, but I fail to see arguments why we should add this to mainline. Well, you have to start somewhere and as this involves asm changes in start.S it would be pretty dangerous add these without being able to test. The idea is that once some version of this patch is in, interested parties can apply the same concept on their boards too. Such testing can be done anywhere, in some test branch. I don't think mainline is the right place for such an intrusive and experiemental feature. Finally, I would like to remind you about [PATCH] PowerPC: Move -fPIC flag to common place I have not seen any test reports on this, so I hesitate to apply it (the move to a common place is no problem, of course, but I'm not sure about changing -fPIC into -fpic). I think I remember problems with this in the past; there have even been commits to use '-fPIC' _instead_ of '-mrelocatable' in the past. I don't remember the details, but I'd like to see some independent testing before this goes in. [PATCH] PowerPC: Add support for -msingle-pic-base Same here. This hits a large number of boards, but I have seen zero test reports. 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 Do you suppose the reason the ends of the `Intel Inside' logo don't match up is that it was drawn on a Pentium? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] NetRxPackets
Dear Marcel, In message 201101182208.33651.korg...@home.nl you wrote: Anyone have an idea how NetRxPackets is allocated ? Nobody ? Well,you're supposed to do some basic code reading yourself. req-buf = (u8 *) NetRxPackets[0]; This is returning an non existing buffer for some reason and I know not much about the ethernet layer to fix this. But you know how to use the search function in your favorite editor, and tools like for example ctags or grep? Hint: have a look at net/net.c. And note: as NetRxPackets[] is a static array I can't see how NetRxPackets[0] should be a non existing buffer. 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 In C we had to code our own bugs, in C++ we can inherit them. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] powerpc: Add LINK_OFF calls in early C-code.
On Tue, 18 Jan 2011 21:39:23 +0100 Joakim Tjernlund joakim.tjernl...@transmode.se wrote: Scott Wood scottw...@freescale.com wrote on 2011/01/18 21:24:16: I don't see why MPC8xx's MMU couldn't be used for this, although it might be a tight fit if you want to get everything into the pinned TLB entries. I think it is harder that that. You probably need a tlb miss handler. Well, as I said, it might be a tight fit. If you can't fit everything within the pinned entries, then you'll need a TLB miss handler, but it could be a simple handler that will insert a non-cacheable identity-mapped entry for whatever address faulted (cacheable regions are covered by pinned entries and won't fault in the first place). Or possibly have an above/below address threshold for determining cacheability. After relocation, you can turn off the MMU, so it's only things you access before relocation that need to fit in the TLB. Should we be talking about all boards, if the only user of this so far is on hardware that can do it in a less-intrusive way? Another thing to keep in mind is that Joakim's approach also won't work on all boards -- you need hardware that is capable of selecting from different entry points, where the entry address itself changes rather than flash banks being flipped around. No, you only need gcc support for msingle-pic-base and some extra RAM to hold the GOT(about 8KB would do I think) while still in flash. Ah, you mean how to select which image to select? That is a small piece of SW that checks both images and chooses the valid one and jumps there. OK, I thought you were using something like a DIP switch to toggle low/high exception vectors, and getting different entry points that way. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3] bugfix: image header pointer change.
Dear Baidu Boy, In message aanlktikznb5ox6-wajjvp1g7kufjygq+4iss2zkrc...@mail.gmail.com you wrote: This patch is still in new state. Please help to check. I think it is really an potential issue without this patch. All your patches require changes. See previous messages about the use of a real name in the Signed-off-by: line. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I'd like to meet the man who invented sex and see what he's working on now. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mpc8378emds: correct the CS0 setting
Dear Baidu Boy, In message 01cbb189$ddf50790$6401a8c0@LENOVOE5CA6843 you wrote: The original CS0 OR configuration sets the reserved field. This patch is to correct the setting. Signed-off-by: Baidu Boy liucai@gmail.com NAK. Real name required. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I'm not a god, I was misquoted. - Lister, Red Dwarf ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] arm: a320 timer: move static data to global_data struct
Dear Po-Yu Chuang, In message aanlktint_7+g+fp2cv5qjb3kqtnbf15y0mm7_s6hb...@mail.gmail.com you wrote: From: Po-Yu Chuang ratb...@faraday-tech.com timer.c used static data and are called before relocation. Move all static variables into global_data structure. Also cleanup timer.c from unused stubs and make it truly use 64 bit tick values. ... Would you please check this patch series? Or should I rebase and resubmit? This is mostly in the responsibility of Albert, the ARM custodian. 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 Presidency: The greased pig in the field game of American politics. - Ambrose Bierce ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/5] mv: seperate kirkwood and armada from common setting
Dear Lei Wen, In message 1294754710-7834-2-git-send-email-lei...@marvell.com you wrote: Since there are lots of difference between kirkwood and armada series, it is better to seperate them but still keep the most common file shared by all marvell platform in the mv-common configure file. This patch move the kirkwood only driver definitoin in mv-common to the soc_name/config.h. This patch is tested with compilation for armada100 and guruplug. Signed-off-by: Lei Wen lei...@marvell.com ... +#ifdef CONFIG_SYS_MVFS Is this a new CONFIG_SYS_* ? Please document it (in the README). Same for all other new CONFIG_* or CONFIG_SYS_*, please. 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 How can you tell when sour cream goes bad? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 2/5] ARM: Add Support for Marvell Pantheon Familiy SoCs
Dear Lei Wen,
In message 1294754710-7834-3-git-send-email-lei...@marvell.com you wrote:
Pantheon Family processors are highly integrated SoCs
based on Sheeva_88SV331x-v5 PJ1 cpu core.
Ref:
http://www.marvell.com/products/processors/communications/marvell_pantheon_910_920_pb.pdf
...
+/* For preventing risk of instability in reading counter value,
+ * first set read request to register cvwr and then read same
+ * register after it captures counter value.
+ */
Incorrect multiline comment style. Please fix globally.
+ulong read_timer(void)
+{
+ struct panthtmr_registers *panthtimers =
+ (struct panthtmr_registers *) PANTHEON_TIMER_BASE;
+ volatile int loop=100;
+
+ writel(COUNT_RD_REQ, panthtimers-cvwr);
+ while (loop--);
Please write this as
while (loop--)
;
Please fix globally.
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
Q: Why do mountain climbers rope themselves together?
A: To prevent the sensible ones from going home.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 4/5] mvmfp: add MFP configuration support for PANTHEON
Dear Lei Wen, In message 1294754710-7834-5-git-send-email-lei...@marvell.com you wrote: This patch adds the support MFP support for Marvell PANTHEON SoCs ... +/* + * Frequently used MFP Configuration macros for all PANTHEON family of +SoCs ^^ + * + * offset, pull,pF, drv,dF, edge,eF ,afn,aF + */ Your code is line wrapped. Please check and fix globally. 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 Shakespeare's Law of Prototyping: (Hamlet III, iv, 156-160) O, throw away the worser part of it, And live the purer with the other half. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [V2 patch 3/4] SMDK6400: Fix build error for nand_spl support
Dear seedshope, In message 1294757545-4771-4-git-send-email-bocui...@gmail.com you wrote: Add some relocation symbols to u-boot.lds and disable LED functions in start.s to support nand_spl. Signed-off-by: seedshope bocui...@gmail.com Please re-split yourpatches. The changes to board/samsung/smdk6400/u-boot.lds and board/samsung/smdk6400/u-boot-nand.lds should probably go into a single commit. Also please chose a more descriptive Subject / commit message. 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 use of anthropomorphic terminology when dealing with computing systems is a symptom of professional immaturity. -- Edsger Dijkstra ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] powerpc: Add LINK_OFF calls in early C-code.
Wolfgang Denk w...@denx.de wrote on 2011/01/18 22:25:04: Dear Joakim Tjernlund, In message ofbbe91305.b19350d9-onc125781c.007192fc-c125781c.00742...@transmode.se you wrote: Ah, finally you make sense to me. I actually tested this with mainline on my board so it is not completely untested in mainline. As your board itself is not in mainline this _is_ completely untested for mainline. It's a nice and appreciated RFC patch or even example implementation, but I fail to see arguments why we should add this to mainline. Well, you have to start somewhere and as this involves asm changes in start.S it would be pretty dangerous add these without being able to test. The idea is that once some version of this patch is in, interested parties can apply the same concept on their boards too. Such testing can be done anywhere, in some test branch. I don't think mainline is the right place for such an intrusive and experiemental feature. Do you have such a branch where you can apply this? Finally, I would like to remind you about [PATCH] PowerPC: Move -fPIC flag to common place I have not seen any test reports on this, so I hesitate to apply it (the move to a common place is no problem, of course, but I'm not sure about changing -fPIC into -fpic). I think I remember problems with this in the past; there have even been commits to use '-fPIC' _instead_ of '-mrelocatable' in the past. I don't remember the details, but I'd like to see some independent testing before this goes in. Right, this can be confusing. Without -mrelocatable you don't get fixups so this has to stay as fixups is a must nowadays. Assuming you don't need fixups, -fpic needs what went into the linker scripts a little while ago so -fpic had little chance before that. [PATCH] PowerPC: Add support for -msingle-pic-base Same here. This hits a large number of boards, but I have seen zero test reports. Scott and Kim, can you give these 2 patches a spin? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] powerpc/8xxx: Add new hwconfig APIs to address early parsing used by DDR init
Dear Kumar Gala,
In message 1294604972-24751-1-git-send-email-ga...@kernel.crashing.org you
wrote:
There are several users of the hwconfig APIs (8xxx DDR) before we have
the environment properly setup. This causes issues because of the
numerous ways the environment might be accessed because of the
non-volatile memory it might be stored in. Additionally the access
might be so early that memory isn't even properly setup for us.
Towards resolving these issues we provide versions of all the hwconfig
APIs that can be passed in a buffer to parse and leave it to the caller
to determine how to allocate and populate the buffer.
We use the _f naming convention for these new APIs even though they are
perfectly useable after relocation and the environment being ready.
We also now warn if the non-f APIs are called before the environment is
ready to allow users to address the issues.
Finally, we convert the 8xxx DDR code to utilize the new APIs to
hopefully address the issue once and for all. We have the 8xxx DDR code
create a buffer on the stack and populate it via getenv_f().
...
I would like to suggest a few changes.
@@ -24,6 +32,15 @@ unsigned int populate_memctl_options(int
all_DIMMs_registered,
unsigned int ctrl_num)
{
unsigned int i;
+ char buffer[HWCONFIG_BUFFER_SIZE];
+ char *buf = NULL;
+
+ /*
+ * Extract hwconfig from environment since we have not properly setup
+ * the environment but need it for ddr config params
+ */
+ if (getenv_f(hwconfig, buffer, sizeof(buffer)) 0)
+ buf = buffer;
If we already know that there is no hwconfig setting in the
environment, why do we then need to go through all the
hwconfig_sub_f() and hwconfig_subarg_cmp_f() calls below?
Can we not short-cut all these?
#ifdef CONFIG_DDR_SPD
+ char buffer[HWCONFIG_BUFFER_SIZE];
+ char *buf = NULL;
+
+ /*
+ * Extract hwconfig from environment since we have not properly setup
+ * the environment but need it for ddr config params
+ */
+ if (getenv_f(hwconfig, buffer, sizeof(buffer)) 0)
+ buf = buffer;
Ditto here.
diff --git a/common/hwconfig.c b/common/hwconfig.c
index 193863a..f909fa5 100644
--- a/common/hwconfig.c
+++ b/common/hwconfig.c
...
-static const char *__hwconfig(const char *opt, size_t *arglen)
+static const char *__hwconfig(const char *opt, size_t *arglen, char *buf)
{
const char *env_hwconfig = NULL, *ret;
- char buf[HWCONFIG_PRE_RELOC_BUF_SIZE];
- if (gd-flags GD_FLG_ENV_READY) {
- env_hwconfig = getenv(hwconfig);
+ /* if we are passed a buffer use it, otherwise try the environment */
+ if (!buf) {
+ if (gd-flags GD_FLG_ENV_READY) {
+ env_hwconfig = getenv(hwconfig);
+ } else {
+ printf(WARNING: Calling __hwconfig without a buffer
+ and before environment is ready\n);
+ return NULL;
+ }
} else {
- /*
- * Use our own on stack based buffer before relocation to allow
- * accessing longer hwconfig strings that might be in the
- * environment before we've relocated. This is pretty fragile
- * on both the use of stack and if the buffer is big enough.
- * However we will get a warning from getenv_f for the later.
- */
- if ((getenv_f(hwconfig, buf, sizeof(buf))) 0)
- env_hwconfig = buf;
+ env_hwconfig = buf;
}
Do we need buf at all?
Make this:
static const char *__hwconfig(const char *opt, size_t *arglen, const char
*env_hwconfig)
...
if (!env_hwconfig) {
if (!(gd-flags GD_FLG_ENV_READY)) {
printf(WARNING: Calling __hwconfig without a buffer
and before environment is ready\n);
return NULL;
}
env_hwconfig = getenv(hwconfig);
}
May I ask what is the size impact of this change (i. e. all the
additional parameter passing) ?
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 amount of time between slipping on the peel and landing on the
pavement is precisely 1 bananosecond.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] ppc, 8xx: remove obsolete km8xx boards from keymile
Dear holger.bru...@keymile.com, In message 1295354730-7947-1-git-send-email-holger.bru...@keymile.com you wrote: From: Holger Brunck holger.bru...@keymile.com The MPC852 based mgsuvd and kmsupx4 boards from keymile were initially ported but later on not developed further. So the respective files were removed to avoid unneeded merging and maintenance. Signed-off-by: Holger Brunck holger.bru...@keymile.com Acked-by: Heiko Schocherh...@denx.de --- Changes for v3: - resend unchanged, because of corrupted lines in previous version Changes for v2: - fix typos in commit message - remove boards from MAINTAINERS file MAINTAINERS |2 - board/keymile/km8xx/Makefile | 48 - board/keymile/km8xx/km8xx.c | 197 --- board/keymile/km8xx/km8xx_hdlc_enet.c | 278 --- board/keymile/km8xx/u-boot.lds| 97 -- boards.cfg|2 - include/configs/km8xx.h | 332 - include/configs/kmsupx4.h | 43 - include/configs/mgsuvd.h | 40 9 files changed, 0 insertions(+), 1039 deletions(-) delete mode 100644 board/keymile/km8xx/Makefile delete mode 100644 board/keymile/km8xx/km8xx.c delete mode 100644 board/keymile/km8xx/km8xx_hdlc_enet.c delete mode 100644 board/keymile/km8xx/u-boot.lds delete mode 100644 include/configs/km8xx.h delete mode 100644 include/configs/kmsupx4.h delete mode 100644 include/configs/mgsuvd.h Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Experience is what causes a person to make new mistakes instead of old ones. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Net: Add Intel E1000 82574L PCIe card support
Dear Roy Zang, In message 1295351719-2687-1-git-send-email-tie-fei.z...@freescale.com you wrote: Add Intel E1000 82574L PCIe card support. Test on MPC8544DS and MPC8572 board. Add the missing contact information for future support. Signed-off-by: Roy Zang tie-fei.z...@freescale.com --- based on commit e1ccf97c5d7651664d37c0c5aa243874b8851b2d drivers/net/e1000.c | 35 +++ drivers/net/e1000.h | 11 +++ include/pci_ids.h |1 + 3 files changed, 39 insertions(+), 8 deletions(-) diff --git a/drivers/net/e1000.c b/drivers/net/e1000.c index 5f390bd..a545cd1 100644 --- a/drivers/net/e1000.c +++ b/drivers/net/e1000.c @@ -40,6 +40,10 @@ tested on both gig copper and gig fiber boards * Copyright (C) Linux Networx. * Massive upgrade to work with the new intel gigabit NICs. * ebiederman at lnxi dot com + * + * Copyright 2009, 2011 Freescale Semiconductor, Inc. + * Authors: Roy Zang tie-fei.z...@freescale.com + * - Add PCI Express card support in Jul. 2009 */ Jul. 2009 ??? diff --git a/drivers/net/e1000.h b/drivers/net/e1000.h index eb0804b..4c60b70 100644 --- a/drivers/net/e1000.h +++ b/drivers/net/e1000.h @@ -24,12 +24,18 @@ Linux NICS linux.n...@intel.com Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR 97124-6497 + ***/ Please drop the additional blank line +/* Copyright 2009, 2011 Freescale Semiconductor, Inc. + * Authors: Roy Zang tie-fei.z...@freescale.com + * - Add PCI Express card support in Jul. 2009 + */ If you really insist on adding this, thenmove it up into the header. What what exactly do you claim Copyright for - for these 4 lines of code? Also, is this really Jul. 2009? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de As a general rule, the freedom of any people can be judged by the volume of their laughter. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2 v2] mpc5200, digsy_mtc: add support for rev5 board version
Dear Heiko Schocher, In message 1294903500-2018-1-git-send-email...@denx.de you wrote: difference to previous board version: - M29W128GH flash from Numonyx - SDRAM ISSI IS45S16800 (Option A2 105°C) - rev5 uses RTC RV-3029-C2 - update cs0 and cs1 baseaddr and length depending on the detected flash size. - added Werner Pfister pfister_wer...@intercontrol.de as maintainer for the digsy board variants - As the M29W128GH needs a special flash_cmd_reset() document that in the new file doc/README.cfi. - move #endif /* CONFIG_CMD_IDE */ to the right place - remove LOWBOOT config option for digsy_mtc and digsy_mtc_rev5 boards - change doc/README.cfi as Stefan Roese suggested Signed-off-by: Heiko Schocher h...@denx.de Signed-off-by: Stefan Roese s...@denx.de cc: Wolfgang Denk h...@denx.de cc: Stefan Roese s...@denx.de cc: Werner Pfister pfister_wer...@intercontrol.de cc: Detlev Zundel d...@denx.de Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de You're dead, Jim. -- McCoy, Amok Time, stardate 3372.7 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] rtc: add support for Micro Crystal RV-3029-C2 RTC
Dear Heiko Schocher, In message 1294816806-32614-1-git-send-email...@denx.de you wrote: Signed-off-by: Heiko Schocher h...@denx.de --- drivers/rtc/Makefile |1 + drivers/rtc/rv3029.c | 124 ++ 2 files changed, 125 insertions(+), 0 deletions(-) create mode 100644 drivers/rtc/rv3029.c Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de It's all Klatchian to me. - Terry Pratchett Stephen Briggs, _The Discworld Companion_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] NetRxPackets
Hi Wolfgang, Nobody ? Well,you're supposed to do some basic code reading yourself. Of course. It's always the idea to post a question after reading for some time. It either means I don't understand the code, the code really doesn't work or I did miss the most important part in the documents. I guess the answer will follow once the issue is solved. To be specific, I work with the u-boot-usb at91-cdc branch code. I'm not sure if that is all working code at this moment but sounded like the best starting point for my USB code. req-buf = (u8 *) NetRxPackets[0]; This is returning an non existing buffer for some reason and I know not much about the ethernet layer to fix this. But you know how to use the search function in your favorite editor, and tools like for example ctags or grep? Hint: have a look at net/net.c. I found that, but it doesn't make sense to me. I'll read it again and hopefully it makes sense to me than. Anyway, my knowledge of the ethernet part in u-boot is limited and I do not focus on ethernet. I will not use ether.c in the end anyway and I was just hoping it would work as a basis to test my new controller code. And note: as NetRxPackets[] is a static array I can't see how NetRxPackets[0] should be a non existing buffer. Well, I guess the point where that's done doesn't show up nicely with grep. I probably missed it and will start to read the ethernet code. I know little of the ethernet code so I feel that as of tomorrow I will skip ether.c and move on to implementing another driver for testing my controller code. My feeling is that I miss something very simple, but I can be looking for it for days. Perhaps I missed some define or whatever, but I'm almost certain that I missed something extremely simple that causes NetRxPackets to be empty somehow. regards, Marcel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] lib: add crc7 from Linux
Dear Thomas Chou, In message 1294709900-2764-1-git-send-email-tho...@wytron.com.tw you wrote: Crc7 is used to compute mmc spi command packet checksum. Copy from linux-2.6 lib/crc7.c include/linux/crc7.h commit ad241528c4919505afccb022acbab3eeb0db4d80 Signed-off-by: Thomas Chou tho...@wytron.com.tw --- v2 update attribution as Wolfgang suggested. include/linux/crc7.h | 14 +++ lib/Makefile |1 + lib/crc7.c | 62 ++ 3 files changed, 77 insertions(+), 0 deletions(-) create mode 100644 include/linux/crc7.h create mode 100644 lib/crc7.c Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de A witty saying proves nothing, but saying something pointless gets people's attention. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] powerpc/8xxx: Add new hwconfig APIs to address early parsing used by DDR init
On Jan 18, 2011, at 4:26 PM, Wolfgang Denk wrote:
Dear Kumar Gala,
In message 1294604972-24751-1-git-send-email-ga...@kernel.crashing.org you
wrote:
There are several users of the hwconfig APIs (8xxx DDR) before we have
the environment properly setup. This causes issues because of the
numerous ways the environment might be accessed because of the
non-volatile memory it might be stored in. Additionally the access
might be so early that memory isn't even properly setup for us.
Towards resolving these issues we provide versions of all the hwconfig
APIs that can be passed in a buffer to parse and leave it to the caller
to determine how to allocate and populate the buffer.
We use the _f naming convention for these new APIs even though they are
perfectly useable after relocation and the environment being ready.
We also now warn if the non-f APIs are called before the environment is
ready to allow users to address the issues.
Finally, we convert the 8xxx DDR code to utilize the new APIs to
hopefully address the issue once and for all. We have the 8xxx DDR code
create a buffer on the stack and populate it via getenv_f().
...
I would like to suggest a few changes.
@@ -24,6 +32,15 @@ unsigned int populate_memctl_options(int
all_DIMMs_registered,
unsigned int ctrl_num)
{
unsigned int i;
+char buffer[HWCONFIG_BUFFER_SIZE];
+char *buf = NULL;
+
+/*
+ * Extract hwconfig from environment since we have not properly setup
+ * the environment but need it for ddr config params
+ */
+if (getenv_f(hwconfig, buffer, sizeof(buffer)) 0)
+buf = buffer;
If we already know that there is no hwconfig setting in the
environment, why do we then need to go through all the
hwconfig_sub_f() and hwconfig_subarg_cmp_f() calls below?
Can we not short-cut all these?
Short cut how?
#ifdef CONFIG_DDR_SPD
+char buffer[HWCONFIG_BUFFER_SIZE];
+char *buf = NULL;
+
+/*
+ * Extract hwconfig from environment since we have not properly setup
+ * the environment but need it for ddr config params
+ */
+if (getenv_f(hwconfig, buffer, sizeof(buffer)) 0)
+buf = buffer;
Ditto here.
diff --git a/common/hwconfig.c b/common/hwconfig.c
index 193863a..f909fa5 100644
--- a/common/hwconfig.c
+++ b/common/hwconfig.c
...
-static const char *__hwconfig(const char *opt, size_t *arglen)
+static const char *__hwconfig(const char *opt, size_t *arglen, char *buf)
{
const char *env_hwconfig = NULL, *ret;
-char buf[HWCONFIG_PRE_RELOC_BUF_SIZE];
-if (gd-flags GD_FLG_ENV_READY) {
-env_hwconfig = getenv(hwconfig);
+/* if we are passed a buffer use it, otherwise try the environment */
+if (!buf) {
+if (gd-flags GD_FLG_ENV_READY) {
+env_hwconfig = getenv(hwconfig);
+} else {
+printf(WARNING: Calling __hwconfig without a buffer
+and before environment is ready\n);
+return NULL;
+}
} else {
-/*
- * Use our own on stack based buffer before relocation to allow
- * accessing longer hwconfig strings that might be in the
- * environment before we've relocated. This is pretty fragile
- * on both the use of stack and if the buffer is big enough.
- * However we will get a warning from getenv_f for the later.
- */
-if ((getenv_f(hwconfig, buf, sizeof(buf))) 0)
-env_hwconfig = buf;
+env_hwconfig = buf;
}
Do we need buf at all?
Make this:
static const char *__hwconfig(const char *opt, size_t *arglen, const char
*env_hwconfig)
...
if (!env_hwconfig) {
if (!(gd-flags GD_FLG_ENV_READY)) {
printf(WARNING: Calling __hwconfig without a buffer
and before environment is ready\n);
return NULL;
}
env_hwconfig = getenv(hwconfig);
}
changed made.
May I ask what is the size impact of this change (i. e. all the
additional parameter passing) ?
For MPC8572DS_config
textdata bss dec hex filename
393964 49144 41752 484860 765fc u-boot [before]
394147 49152 41752 485051 766bb u-boot [after]
183 8 191
- k
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Net: Add Intel E1000 82574L PCIe card support
On Jan 18, 2011, at 4:33 PM, Wolfgang Denk wrote: Dear Roy Zang, In message 1295351719-2687-1-git-send-email-tie-fei.z...@freescale.com you wrote: Add Intel E1000 82574L PCIe card support. Test on MPC8544DS and MPC8572 board. Add the missing contact information for future support. Signed-off-by: Roy Zang tie-fei.z...@freescale.com --- based on commit e1ccf97c5d7651664d37c0c5aa243874b8851b2d drivers/net/e1000.c | 35 +++ drivers/net/e1000.h | 11 +++ include/pci_ids.h |1 + 3 files changed, 39 insertions(+), 8 deletions(-) diff --git a/drivers/net/e1000.c b/drivers/net/e1000.c index 5f390bd..a545cd1 100644 --- a/drivers/net/e1000.c +++ b/drivers/net/e1000.c @@ -40,6 +40,10 @@ tested on both gig copper and gig fiber boards * Copyright (C) Linux Networx. * Massive upgrade to work with the new intel gigabit NICs. * ebiederman at lnxi dot com + * + * Copyright 2009, 2011 Freescale Semiconductor, Inc. + * Authors: Roy Zang tie-fei.z...@freescale.com + * - Add PCI Express card support in Jul. 2009 */ Jul. 2009 ??? diff --git a/drivers/net/e1000.h b/drivers/net/e1000.h index eb0804b..4c60b70 100644 --- a/drivers/net/e1000.h +++ b/drivers/net/e1000.h @@ -24,12 +24,18 @@ Linux NICS linux.n...@intel.com Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR 97124-6497 + ***/ Please drop the additional blank line +/* Copyright 2009, 2011 Freescale Semiconductor, Inc. + * Authors: Roy Zang tie-fei.z...@freescale.com + * - Add PCI Express card support in Jul. 2009 + */ If you really insist on adding this, thenmove it up into the header. What what exactly do you claim Copyright for - for these 4 lines of code? Also, is this really Jul. 2009? I think Roy is referencing the following commit in which he added support for numerous e1000 PCIe variants: commit aa0707897c49c330b7d6b8d8362e44f60f224732 Author: Roy Zang tie-fei.z...@freescale.com Date: Fri Jul 31 13:34:02 2009 +0800 Add Intel E1000 PCIE card support - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4 v2] spi: add spi_set_speed func
Dear Thomas Chou, In message 1293232433-2985-1-git-send-email-tho...@wytron.com.tw you wrote: This func helps mmc_spi driver set correct speed for mmc/sd, as mmc card needs 400KHz clock for spi mode initialization. Signed-off-by: Thomas Chou tho...@wytron.com.tw --- v2 remove weak func as Mike suggested. include/spi.h |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/include/spi.h b/include/spi.h index 320e50e..7887d0f 100644 --- a/include/spi.h +++ b/include/spi.h @@ -176,6 +176,14 @@ void spi_cs_activate(struct spi_slave *slave); void spi_cs_deactivate(struct spi_slave *slave); /*--- + * Set transfer speed. + * This sets a new speed to be applied for next spi_xfer(). + * slave: The SPI slave + * hz: The transfer speed + */ Incorrect multiline comment style. 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 Wenn Du ein' weise Antwort verlangst, Mußt Du vernünftig fragen. -- Goethe, Invektiven ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] powerpc: Add LINK_OFF calls in early C-code.
Dear Joakim Tjernlund, In message ofa95d19c0.58c4cbc0-onc125781c.00785fed-c125781c.0079e...@transmode.se you wrote: Such testing can be done anywhere, in some test branch. I don't think mainline is the right place for such an intrusive and experiemental feature. Do you have such a branch where you can apply this? But I'm have no plans to test it. I don't have time nor resources for that. 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 Get back to your stations! We're beaming down to the planet, sir. -- Kirk and Mr. Leslie, This Side of Paradise, stardate 3417.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] powerpc/8xxx: Add new hwconfig APIs to address early parsing used by DDR init
There are several users of the hwconfig APIs (8xxx DDR) before we have
the environment properly setup. This causes issues because of the
numerous ways the environment might be accessed because of the
non-volatile memory it might be stored in. Additionally the access
might be so early that memory isn't even properly setup for us.
Towards resolving these issues we provide versions of all the hwconfig
APIs that can be passed in a buffer to parse and leave it to the caller
to determine how to allocate and populate the buffer.
We use the _f naming convention for these new APIs even though they are
perfectly useable after relocation and the environment being ready.
We also now warn if the non-f APIs are called before the environment is
ready to allow users to address the issues.
Finally, we convert the 8xxx DDR code to utilize the new APIs to
hopefully address the issue once and for all. We have the 8xxx DDR code
create a buffer on the stack and populate it via getenv_f().
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
* Reworked __hwconfig to not require an additional local var per WD's comments
arch/powerpc/cpu/mpc8xxx/ddr/options.c | 78 ++---
common/hwconfig.c | 86 ---
include/hwconfig.h | 68 +++--
3 files changed, 154 insertions(+), 78 deletions(-)
diff --git a/arch/powerpc/cpu/mpc8xxx/ddr/options.c
b/arch/powerpc/cpu/mpc8xxx/ddr/options.c
index c641e85..0e7097b 100644
--- a/arch/powerpc/cpu/mpc8xxx/ddr/options.c
+++ b/arch/powerpc/cpu/mpc8xxx/ddr/options.c
@@ -13,6 +13,14 @@
#include ddr.h
+/*
+ * Use our own stack based buffer before relocation to allow accessing longer
+ * hwconfig strings that might be in the environment before we've relocated.
+ * This is pretty fragile on both the use of stack and if the buffer is big
+ * enough. However we will get a warning from getenv_f for the later.
+ */
+#define HWCONFIG_BUFFER_SIZE 128
+
/* Board-specific functions defined in each board's ddr.c */
extern void fsl_ddr_board_options(memctl_options_t *popts,
dimm_params_t *pdimm,
@@ -24,6 +32,15 @@ unsigned int populate_memctl_options(int
all_DIMMs_registered,
unsigned int ctrl_num)
{
unsigned int i;
+ char buffer[HWCONFIG_BUFFER_SIZE];
+ char *buf = NULL;
+
+ /*
+* Extract hwconfig from environment since we have not properly setup
+* the environment but need it for ddr config params
+*/
+ if (getenv_f(hwconfig, buffer, sizeof(buffer)) 0)
+ buf = buffer;
/* Chip select options. */
@@ -221,7 +238,7 @@ unsigned int populate_memctl_options(int
all_DIMMs_registered,
* should be a subset of the requested configuration.
*/
#if (CONFIG_NUM_DDR_CONTROLLERS 1)
- if (hwconfig_sub(fsl_ddr, ctlr_intlv)) {
+ if (hwconfig_sub_f(fsl_ddr, ctlr_intlv, buf)) {
if (pdimm[0].n_ranks == 0) {
printf(There is no rank on CS0 for controller %d.
Because only
rank on CS0 and ranks chip-select interleaved
with CS0
@@ -234,19 +251,25 @@ unsigned int populate_memctl_options(int
all_DIMMs_registered,
* test null first. if CONFIG_HWCONFIG is not defined
* hwconfig_arg_cmp returns non-zero
*/
- if (hwconfig_subarg_cmp(fsl_ddr, ctlr_intlv,
null)) {
+ if (hwconfig_subarg_cmp_f(fsl_ddr, ctlr_intlv,
+ null, buf)) {
popts-memctl_interleaving = 0;
debug(memory controller interleaving
disabled.\n);
- } else if (hwconfig_subarg_cmp(fsl_ddr, ctlr_intlv,
cacheline))
+ } else if (hwconfig_subarg_cmp_f(fsl_ddr,
+ctlr_intlv,
+cacheline, buf))
popts-memctl_interleaving_mode =
FSL_DDR_CACHE_LINE_INTERLEAVING;
- else if (hwconfig_subarg_cmp(fsl_ddr, ctlr_intlv,
page))
+ else if (hwconfig_subarg_cmp_f(fsl_ddr, ctlr_intlv,
+ page, buf))
popts-memctl_interleaving_mode =
FSL_DDR_PAGE_INTERLEAVING;
- else if (hwconfig_subarg_cmp(fsl_ddr, ctlr_intlv,
bank))
+ else if (hwconfig_subarg_cmp_f(fsl_ddr, ctlr_intlv,
+ bank, buf))
popts-memctl_interleaving_mode =
FSL_DDR_BANK_INTERLEAVING;
-
Re: [U-Boot] [PATCH v2 2/2] powerpc/8xxx: Add new hwconfig APIs to address early parsing used by DDR init
On Jan 18, 2011, at 4:40 PM, Kumar Gala wrote: If we already know that there is no hwconfig setting in the environment, why do we then need to go through all the hwconfig_sub_f() and hwconfig_subarg_cmp_f() calls below? Can we not short-cut all these? Short cut how? while we could clean this up, I'm leaving it alone in this patch as its not the goal of this patch to rework the world, just trying to fix hwconfig for use early. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] NetRxPackets
Dear Marcel, Well,you're supposed to do some basic code reading yourself. Of course. It's always the idea to post a question after reading for some time. It either means I don't understand the code, the code really doesn't work or I did miss the most important part in the documents. I guess the answer will follow once the issue is solved. To be specific, I work with the u-boot-usb at91-cdc branch code. I'm not sure if that is all working code at this moment but sounded like the best starting point for my USB code. Not sure that branch is anything up to date req-buf = (u8 *) NetRxPackets[0]; *maybe* req itself is not allocated? Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Net: Add Intel E1000 82574L PCIe card support
Dear Kumar Gala, In message 7de856f6-e8eb-43bb-b641-60d84e33a...@kernel.crashing.org you wrote: + * Authors: Roy Zang tie-fei.z...@freescale.com + * - Add PCI Express card support in Jul. 2009 + */ If you really insist on adding this, thenmove it up into the header. What what exactly do you claim Copyright for - for these 4 lines of code? Also, is this really Jul. 2009? I think Roy is referencing the following commit in which he added support for numerous e1000 PCIe variants: commit aa0707897c49c330b7d6b8d8362e44f60f224732 Author: Roy Zang tie-fei.z...@freescale.com Date: Fri Jul 31 13:34:02 2009 +0800 Add Intel E1000 PCIE card support That was then, and now is now. I don't see what that old commit has to do with the current one? 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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] Correct chip detect logic
Dear Yanjun Yang, In message AANLkTi=YN=ADLKGTmsoFGBG5ZuaO=ashhe_3o5kqv...@mail.gmail.com you wrote: The lan91c96_detect_chip routine is not correct according to the manual. Signed-off-by: YanJun Yang yangyj...@gmail.com --- Changes for v2: - Avoid line wraps and ensure tabs - Don't define a new macro drivers/net/lan91c96.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I think there's a world market for about five computers. -- attr. Thomas J. Watson (Chairman of the Board, IBM), 1943 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Replace FLASH strings with Flash or flash
Dear Peter Tyser, In message 1293581525-18073-1-git-send-email-pty...@xes-inc.com you wrote: There's no compelling reason to have the output on bootup or the flinfo command print flash in uppercase, so use the proper case where appropriate. Signed-off-by: Peter Tyser pty...@xes-inc.com --- arch/arm/lib/board.c|2 +- arch/m68k/lib/board.c |2 +- arch/microblaze/lib/board.c |2 +- arch/powerpc/lib/board.c|2 +- arch/sh/lib/board.c |2 +- arch/sparc/lib/board.c |2 +- board/xes/xpedite517x/xpedite517x.c |2 +- board/xes/xpedite520x/xpedite520x.c |2 +- board/xes/xpedite537x/xpedite537x.c |2 +- board/xes/xpedite550x/xpedite550x.c |2 +- drivers/mtd/cfi_flash.c |4 ++-- 11 files changed, 12 insertions(+), 12 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de A failure will not appear until a unit has passed final inspection. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] cmd_jffs2: Fix get_part_sector_size_nor() overflow bug
Dear Peter Tyser, In message 1293745676-1557-1-git-send-email-pty...@xes-inc.com you wrote: When a flash partition was positioned at the very top of a 32-bit memory map (eg located at 0xf800 with a size of 0x800) get_part_sector_size_nor() would incorrectly calculate the partition's ending address to 0x0 due to overflow. When the overflow occurred get_part_sector_size_nor() would falsely return a sector size of 0. A sector size of 0 results in subsequent jffs2 operations failing. To workaround the overflow subtract 1 from calculated address of the partition endpoint. Signed-off-by: Peter Tyser pty...@xes-inc.com --- common/cmd_jffs2.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Applied. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I am a computer. I am dumber than any human and smarter than any ad- ministrator. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] Fix typo (comand instead of command)
Dear =?UTF-8?q?Lo=C3=AFc=20Minier?=, In message 1294104756-3338-1-git-send-email-loic.min...@linaro.org you wrote: Signed-off-by: Loïc Minier loic.min...@linaro.org --- tools/kwbimage.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Drawing on my fine command of language, I said nothing. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] Escape minus signs in manpage
Dear =?UTF-8?q?Lo=C3=AFc=20Minier?=, In message 1294104756-3338-2-git-send-email-loic.min...@linaro.org you wrote: By default, - chars are interpreted as hyphens (U+2010) by groff, not as minus signs (U+002D). Since options to programs use minus signs (U+002D), this means for example in UTF-8 locales that you cannot cut and paste options, nor search for them easily. (Reported by lintian.) Signed-off-by: Loïc Minier loic.min...@linaro.org --- doc/mkimage.1 |8 1 files changed, 4 insertions(+), 4 deletions(-) appplied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Due to lack of disk space, this fortune database has been discontinued. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] env: make import/export optional
Dear Mike Frysinger, In message 1294638366-32527-1-git-send-email-vap...@gentoo.org you wrote: Signed-off-by: Mike Frysinger vap...@gentoo.org --- common/cmd_nvedit.c |8 include/config_cmd_defaults.h |2 ++ 2 files changed, 10 insertions(+), 0 deletions(-) diff --git a/common/cmd_nvedit.c b/common/cmd_nvedit.c index fb69c24..715dffd 100644 --- a/common/cmd_nvedit.c +++ b/common/cmd_nvedit.c @@ -559,6 +559,7 @@ static int do_env_delete(cmd_tbl_t * cmdtp, int flag, int argc, char * const arg return 0; } +#ifdef CONFIG_CMD_EXPORTENV ... +#ifdef CONFIG_CMD_IMPORTENV Please document the new CONFIG_CMD_* options. 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 Artificial Intelligence is no match for natural stupidity. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3 RESEND] MX51EVK: Use SWx macros in PMIC init
Signed-off-by: Marek Vasut marek.va...@gmail.com --- board/freescale/mx51evk/mx51evk.c |7 --- 1 files changed, 4 insertions(+), 3 deletions(-) diff --git a/board/freescale/mx51evk/mx51evk.c b/board/freescale/mx51evk/mx51evk.c index 2160d5a..bcf1934 100644 --- a/board/freescale/mx51evk/mx51evk.c +++ b/board/freescale/mx51evk/mx51evk.c @@ -198,17 +198,18 @@ static void power_init(void) /* Set core voltage to 1.1V */ val = pmic_reg_read(REG_SW_0); - val = (val (~0x1F)) | 0x14; + val = (val (~SWx_VOLT_MASK)) | SWx_1_100V; pmic_reg_write(REG_SW_0, val); /* Setup VCC (SW2) to 1.25 */ val = pmic_reg_read(REG_SW_1); - val = (val (~0x1F)) | 0x1A; + val = (val (~SWx_VOLT_MASK)) | SWx_1_250V; + pmic_reg_write(REG_SW_1, val); /* Setup 1V2_DIG1 (SW3) to 1.25 */ val = pmic_reg_read(REG_SW_2); - val = (val (~0x1F)) | 0x1A; + val = (val (~SWx_VOLT_MASK)) | SWx_1_250V; pmic_reg_write(REG_SW_2, val); udelay(50); -- 1.7.2.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3 v2] MC13892: Add SWx buck switchers definitions
Define voltages configurable on SWx buck switchers. Signed-off-by: Marek Vasut marek.va...@gmail.com --- v2: Add note about SWxHI include/mc13892.h | 39 +++ 1 files changed, 39 insertions(+), 0 deletions(-) diff --git a/include/mc13892.h b/include/mc13892.h index 61c3e6e..a1078a5 100644 --- a/include/mc13892.h +++ b/include/mc13892.h @@ -160,4 +160,43 @@ /* Reg Power Control 2*/ #define WDIRESET (1 12) +/* Buck Switchers (SW1,2,3,4) Output Voltage */ +/* + * NOTE: These values are for SWxHI = 0, + * SWxHI = 1 adds 0.5V to the desired voltage + */ +#define SWx_0_600V 0 +#define SWx_0_625V 1 +#define SWx_0_650V 2 +#define SWx_0_675V 3 +#define SWx_0_700V 4 +#define SWx_0_725V 5 +#define SWx_0_750V 6 +#define SWx_0_775V 7 +#define SWx_0_800V 8 +#define SWx_0_825V 9 +#define SWx_0_850V 10 +#define SWx_0_875V 11 +#define SWx_0_900V 12 +#define SWx_0_925V 13 +#define SWx_0_950V 14 +#define SWx_0_975V 15 +#define SWx_1_000V 16 +#define SWx_1_025V 17 +#define SWx_1_050V 18 +#define SWx_1_075V 19 +#define SWx_1_100V 20 +#define SWx_1_125V 21 +#define SWx_1_150V 22 +#define SWx_1_175V 23 +#define SWx_1_200V 24 +#define SWx_1_225V 25 +#define SWx_1_250V 26 +#define SWx_1_275V 27 +#define SWx_1_300V 28 +#define SWx_1_325V 29 +#define SWx_1_350V 30 +#define SWx_1_375V 31 +#define SWx_VOLT_MASK 0x1F + #endif -- 1.7.2.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3 v4] iMX5: EfikaMX: Preliminary board support
Supported: MMC IDE PMIC SPI flash LEDs I can boot the kernel supplied by freescale/genesi with this from MMC card and/or PATA disk. Signed-off-by: Marek Vasut marek.va...@gmail.com --- v4: * Remove NOTE: if (is_soc_rev(CHIP_REV_2_0) = 0) comment * Fix bold multiline comments MAINTAINERS|1 + board/efikamx/Makefile | 52 board/efikamx/config.mk| 25 ++ board/efikamx/efikamx.c| 693 board/efikamx/imximage.cfg | 122 boards.cfg |1 + include/configs/efikamx.h | 232 +++ 7 files changed, 1126 insertions(+), 0 deletions(-) create mode 100644 board/efikamx/Makefile create mode 100644 board/efikamx/config.mk create mode 100644 board/efikamx/efikamx.c create mode 100644 board/efikamx/imximage.cfg create mode 100644 include/configs/efikamx.h diff --git a/MAINTAINERS b/MAINTAINERS index a799037..8f1b1b6 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -823,6 +823,7 @@ Marek Vasut marek.va...@gmail.com palmtc xscale vpac270 xscale zipitz2 xscale + efikamx i.MX51 Hugo Villeneuve hugo.villene...@lyrtech.com diff --git a/board/efikamx/Makefile b/board/efikamx/Makefile new file mode 100644 index 000..ee4a16e --- /dev/null +++ b/board/efikamx/Makefile @@ -0,0 +1,52 @@ +# +# Copyright (C) 2010, Marek Vasut marek.va...@gmail.com +# +# BASED ON: imx51evk +# +# Copyright (C) 2007, Guennadi Liakhovetski l...@denx.de +# +# (C) Copyright 2009 Freescale Semiconductor, Inc. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# 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).o + +COBJS := efikamx.o + +SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS)) +SOBJS := $(addprefix $(obj),$(SOBJS)) + +$(LIB):$(obj).depend $(OBJS) $(SOBJS) + $(call cmd_link_o_target, $(OBJS) $(SOBJS)) + +clean: + rm -f $(SOBJS) $(OBJS) + +distclean: clean + rm -f $(LIB) core *.bak .depend + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/board/efikamx/config.mk b/board/efikamx/config.mk new file mode 100644 index 000..6e90671 --- /dev/null +++ b/board/efikamx/config.mk @@ -0,0 +1,25 @@ +# +# Copyright 2009 Freescale Semiconductor, Inc. All Rights Reserved. +# +# 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 +# + +CONFIG_SYS_TEXT_BASE = 0x9780 +IMX_CONFIG = $(SRCTREE)/board/$(BOARDDIR)/imximage.cfg +ALL += $(obj)u-boot.imx diff --git a/board/efikamx/efikamx.c b/board/efikamx/efikamx.c new file mode 100644 index 000..e98ce9c --- /dev/null +++ b/board/efikamx/efikamx.c @@ -0,0 +1,693 @@ +/* + * Copyright (C) 2010 Marek Vasut marek.va...@gmail.com + * + * (C) Copyright 2009 Freescale Semiconductor, Inc. + * + * 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.
[U-Boot] [PATCH] Print compiler and linker version with the version command
After years of unsuccessful research I've finally shamelessly stolen other
peoples intellectual properties to present the all-new and world-changing
updated version command:
-
U-Boot version
U-Boot 2010.12-00014-g7435056-dirty (Jan 18 2011 - 23:19:38)
MyBoard
gcc (GCC) 0.42 (Distro foobar)
GNU ld (GNU Binutils) 0.314159265
-
May the toolchain bugs rest in peace.
Signed-off-by: Alexander Holler hol...@ahsoftware.de
---
Makefile |4
common/cmd_version.c |9 -
2 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 9055028..b434212 100644
--- a/Makefile
+++ b/Makefile
@@ -416,6 +416,10 @@ $(U_BOOT_ONENAND): $(ONENAND_IPL) $(obj)u-boot.bin
$(VERSION_FILE):
@( printf '#define U_BOOT_VERSION U-Boot %s%s\n'
$(U_BOOT_VERSION) \
'$(shell $(TOPDIR)/tools/setlocalversion $(TOPDIR))' ) $@.tmp
+ @( printf '#define CC_VERSION_STRING %s\n' \
+'$(shell $(CC) --version | head -n 1)' ) $@.tmp
+ @( printf '#define LD_VERSION_STRING %s\n' \
+'$(shell $(LD) -v | head -n 1)' ) $@.tmp
@cmp -s $@ $@.tmp rm -f $@.tmp || mv -f $@.tmp $@
$(TIMESTAMP_FILE):
diff --git a/common/cmd_version.c b/common/cmd_version.c
index 7d1b495..83cb11c 100644
--- a/common/cmd_version.c
+++ b/common/cmd_version.c
@@ -23,18 +23,25 @@
#include common.h
#include command.h
+#include version.h
extern char version_string[];
int do_version(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
printf(\n%s\n, version_string);
+#ifdef CC_VERSION_STRING
+ puts(CC_VERSION_STRING \n);
+#endif
+#ifdef LD_VERSION_STRING
+ puts(LD_VERSION_STRING \n);
+#endif
return 0;
}
U_BOOT_CMD(
version,1, 1, do_version,
- print monitor version,
+ print monitor, compiler and linker version,
);
--
1.7.3.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
