[U-Boot] [PATCH] ppc/85xx:Fix compile err when PCI disabled on P1_P2_RDB
u-boot cannot be compiled after disabling CONFIG_PCI.
Place PCI related codes under #ifdef CONFIG_PCI
Signed-off-by: Prabhakar Kushwaha
---
Based of http://git.denx.de/u-boot.git (branch master)
Top commit:
commit 3f1266d6d5bf14ea7248544db8406d308c6bfa7c
Author: Loïc Minier
Date: Tue Jan 4 02:32:36 2011 +0100
Escape minus signs in manpage
board/freescale/p1_p2_rdb/p1_p2_rdb.c |4 +++-
board/freescale/p1_p2_rdb/tlb.c |4 +++-
include/configs/P1_P2_RDB.h | 13 -
3 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/board/freescale/p1_p2_rdb/p1_p2_rdb.c
b/board/freescale/p1_p2_rdb/p1_p2_rdb.c
index 440fcb9..0780942 100644
--- a/board/freescale/p1_p2_rdb/p1_p2_rdb.c
+++ b/board/freescale/p1_p2_rdb/p1_p2_rdb.c
@@ -1,5 +1,5 @@
/*
- * Copyright 2009-2010 Freescale Semiconductor, Inc.
+ * Copyright 2009-2011 Freescale Semiconductor, Inc.
*
* See file CREDITS for list of people who contributed to this
* project.
@@ -222,7 +222,9 @@ void ft_board_setup(void *blob, bd_t *bd)
base = getenv_bootm_low();
size = getenv_bootm_size();
+#if defined(CONFIG_PCI)
ft_pci_board_setup(blob);
+#endif /* #if defined(CONFIG_PCI) */
fdt_fixup_memory(blob, (u64)base, (u64)size);
}
diff --git a/board/freescale/p1_p2_rdb/tlb.c b/board/freescale/p1_p2_rdb/tlb.c
index 93d0bf7..b85c268 100644
--- a/board/freescale/p1_p2_rdb/tlb.c
+++ b/board/freescale/p1_p2_rdb/tlb.c
@@ -1,5 +1,5 @@
/*
- * Copyright 2009 Freescale Semiconductor, Inc.
+ * Copyright 2011 Freescale Semiconductor, Inc.
*
* See file CREDITS for list of people who contributed to this
* project.
@@ -58,6 +58,7 @@ struct fsl_e_tlb_entry tlb_table[] = {
MAS3_SX|MAS3_SR, MAS2_W|MAS2_G,
0, 2, BOOKE_PAGESZ_16M, 1),
+#if defined(CONFIG_PCI)
/* *I*G* - PCI */
SET_TLB_ENTRY(1, CONFIG_SYS_PCIE2_MEM_VIRT, CONFIG_SYS_PCIE2_MEM_PHYS,
MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
@@ -68,6 +69,7 @@ struct fsl_e_tlb_entry tlb_table[] = {
MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
0, 4, BOOKE_PAGESZ_256K, 1),
+#endif /* #if defined(CONFIG_PCI) */
/* *I*G - NAND */
SET_TLB_ENTRY(1, CONFIG_SYS_NAND_BASE, CONFIG_SYS_NAND_BASE_PHYS,
MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
diff --git a/include/configs/P1_P2_RDB.h b/include/configs/P1_P2_RDB.h
index 80b0b40..033ee1f 100644
--- a/include/configs/P1_P2_RDB.h
+++ b/include/configs/P1_P2_RDB.h
@@ -77,17 +77,23 @@
#define CONFIG_E5001 /* BOOKE e500 family */
#define CONFIG_MPC85xx 1 /* MPC8540/60/55/41/48/P1020/P2020,etc*/
#define CONFIG_FSL_ELBC1 /* Enable eLBC Support */
+
#define CONFIG_PCI 1 /* Enable PCI/PCIE */
+#if defined(CONFIG_PCI)
#define CONFIG_PCIE1 1 /* PCIE controler 1 (slot 1) */
#define CONFIG_PCIE2 1 /* PCIE controler 2 (slot 2) */
#define CONFIG_FSL_PCI_INIT1 /* Use common FSL init code */
#define CONFIG_FSL_PCIE_RESET 1 /* need PCIe reset errata */
#define CONFIG_SYS_PCI_64BIT 1 /* enable 64-bit PCI resources */
+#endif /* #if defined(CONFIG_PCI) */
#define CONFIG_FSL_LAW 1 /* Use common FSL init code */
#define CONFIG_TSEC_ENET /* tsec ethernet support */
#define CONFIG_ENV_OVERWRITE
+#if defined(CONFIG_PCI)
#define CONFIG_E1000 1 /* E1000 pci Ethernet card*/
+#endif
+
#ifndef __ASSEMBLY__
extern unsigned long get_board_sys_clk(unsigned long dummy);
#endif
@@ -358,6 +364,7 @@ extern unsigned long get_board_sys_clk(unsigned long dummy);
*/
/* controller 2, Slot 2, tgtid 2, Base address 9000 */
+#if defined(CONFIG_PCI)
#define CONFIG_SYS_PCIE2_NAME "Slot 1"
#define CONFIG_SYS_PCIE2_MEM_VIRT 0xa000
#define CONFIG_SYS_PCIE2_MEM_BUS 0xa000
@@ -379,8 +386,6 @@ extern unsigned long get_board_sys_clk(unsigned long dummy);
#define CONFIG_SYS_PCIE1_IO_PHYS 0xffc3
#define CONFIG_SYS_PCIE1_IO_SIZE 0x0001 /* 64k */
-#if defined(CONFIG_PCI)
-#define CONFIG_NET_MULTI
#define CONFIG_PCI_PNP /* do pci plug-and-play */
#undef CONFIG_EEPRO100
@@ -399,11 +404,9 @@ extern unsigned long get_board_sys_clk(unsigned long
dummy);
#endif /* CONFIG_PCI */
-#if defined(CONFIG_TSEC_ENET)
-#ifndef CONFIG_NET_MULTI
#define CONFIG_NET_MULTI 1
-#endif
+#if defined(CONFIG_TSEC_ENET)
#define CONFIG_MII 1 /* MII PHY management */
#define CONFIG_MII_DEFAULT_TSEC1 /* Allow unregistered phys */
#define CONFIG_TSEC1 1
--
1.6.3.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] P2020 L2 cache as SRAM
At 09:07 17.01.2011 +0100, Fabian Cenedese wrote: >Hi > >We're trying to configure the PPC P2020 cpu to use the L2 cache >as SRAM so we can load the U-Boot code in there. However we >stumble into problems. Sometimes the cpu goes on trap when >trying to access this area. Sometimes there's no trap but we >seem to access a different area. That's probably a problem with >setting up a TLB/LAW. > >Has anybody already done this and could share some code with >us? > >I've seen that there's a mpc85xx branch with quite some work >going on. Where should we base our work on? Should we use >the master or is it better to use this branch? I'm used to svn, >not git, so there may be other options I don't know about yet. I know you're busy with patches and releasing, I just wanted to ask again if anybody has already done this. Thanks bye Fabi ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/7] mxc_spi: add support for i.MX35 processor
Dear Stefano Babic,
In message <1295012124-15551-6-git-send-email-sba...@denx.de> you wrote:
> Signed-off-by: Stefano Babic
> ---
> drivers/spi/mxc_spi.c | 96
> +
> 1 files changed, 73 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/spi/mxc_spi.c b/drivers/spi/mxc_spi.c
> index d558137..b353c83 100644
> --- a/drivers/spi/mxc_spi.c
> +++ b/drivers/spi/mxc_spi.c
> @@ -70,6 +70,8 @@ static unsigned long spi_bases[] = {
> 0x53f84000,
> };
>
> +#define spi_cfg spi_cfg_mx3
...
> +#define spi_cfg spi_cfg_mx51
Hm... this repeats below, but in the end both spi_cfg_mx3() and
spi_cfg_mx51() are just static functions within the same source file,
with #ifdef's around them so only one can ever be enabled at a time.
I suggest you omit all these "#define spi_cfg" lines and rename both
versions of these functions into spi_cfg_mx().
> +#define MXC_CSPIRXDATA 0x00
> +#define MXC_CSPITXDATA 0x04
> +#define MXC_CSPICTRL 0x08
> +#define MXC_CSPIINT 0x0C
> +#define MXC_CSPIDMA 0x10
> +#define MXC_CSPISTAT 0x14
> +#define MXC_CSPIPERIOD 0x18
> +#define MXC_CSPITEST 0x1C
As mentioned before: please use a C struct.
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
"If you own a machine, you are in turn owned by it, and spend your
time serving it..."- Marion Zimmer Bradley, _The Forbidden Tower_
___
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 Wolfgang Denk, 2011/01/18 18:29, Wolfgang Denk wrote: > Dear Yoshihiro Shimoda, > >> /* 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. Oh, I didn't realize that is sorted by alphabet. I will fix it. Best regards, Yoshihiro Shimoda ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/7] Add basic support for Freescale's mc9sdz60
Dear Stefano Babic, In message <1295012124-15551-5-git-send-email-sba...@denx.de> you wrote: > The patch adds helper funtions for basic access to the registers > of the MC9sdz60 chip (multifunctional device with RTC and CAN) via > I2C interface. > > Signed-off-by: Stefano Babic > --- > drivers/misc/Makefile |1 + > drivers/misc/mc9sdz60.c | 51 > include/mc9sdz60.h | 84 > +++ > 3 files changed, 136 insertions(+), 0 deletions(-) > create mode 100644 drivers/misc/mc9sdz60.c > create mode 100644 include/mc9sdz60.h > > diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile > index a76bd4e..311c373 100644 > --- a/drivers/misc/Makefile > +++ b/drivers/misc/Makefile > @@ -32,6 +32,7 @@ COBJS-$(CONFIG_GPIO_LED) += gpio_led.o > COBJS-$(CONFIG_NS87308) += ns87308.o > COBJS-$(CONFIG_STATUS_LED) += status_led.o > COBJS-$(CONFIG_TWL4030_LED) += twl4030_led.o > +COBJS-$(CONFIG_FSL_MC9SDZ60) += mc9sdz60.o > COBJS-$(CONFIG_FSL_PMIC) += fsl_pmic.o > COBJS-$(CONFIG_PDSP188x) += pdsp188x.o I know it's not your fault, but could you please sort this list? 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 What the gods would destroy they first submit to an IEEE standards committee. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH ] powerpc/85xx: Protect all LBC code with CONFIG_FSL_LBC
Future SoC (like the P1010) replace the LBC controller with the new IFC
(Integrated Flash Controller) so ensure we properly protect code that is
related to the LBC.
Signed-off-by: Dipen Dudhat
Acked-by: Kumar Gala
---
arch/powerpc/cpu/mpc85xx/cpu.c |9 -
arch/powerpc/cpu/mpc85xx/speed.c |6 +-
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/cpu/mpc85xx/cpu.c b/arch/powerpc/cpu/mpc85xx/cpu.c
index 2f5a505..700e292 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu.c
@@ -1,5 +1,5 @@
/*
- * Copyright 2004,2007-2010 Freescale Semiconductor, Inc.
+ * Copyright 2004,2007-2011 Freescale Semiconductor, Inc.
* (C) Copyright 2002, 2003 Motorola Inc.
* Xianghua Xiao (x.x...@motorola.com)
*
@@ -166,12 +166,14 @@ int checkcpu (void)
}
#endif
+#if defined(CONFIG_FSL_LBC)
if (sysinfo.freqLocalBus > LCRR_CLKDIV) {
printf("LBC:%-4s MHz\n", strmhz(buf1, sysinfo.freqLocalBus));
} else {
printf("LBC: unknown (LCRR[CLKDIV] = 0x%02lx)\n",
sysinfo.freqLocalBus);
}
+#endif
#ifdef CONFIG_CPM2
printf("CPM: %s MHz\n", strmhz(buf1, sysinfo.freqSystemBus));
@@ -284,7 +286,10 @@ void mpc85xx_reginfo(void)
{
print_tlbcam();
print_laws();
+#if defined(CONFIG_FSL_LBC)
print_lbc_regs();
+#endif
+
}
/* Common ddr init for non-corenet fsl 85xx platforms */
@@ -330,8 +335,10 @@ phys_size_t initdram(int board_type)
ddr_enable_ecc(dram_size);
#endif
+#if defined(CONFIG_FSL_LBC)
/* Some boards also have sdram on the lbc */
lbc_sdram_init();
+#endif
puts("DDR: ");
return dram_size;
diff --git a/arch/powerpc/cpu/mpc85xx/speed.c b/arch/powerpc/cpu/mpc85xx/speed.c
index dd4c6b3..f2aa8d0 100644
--- a/arch/powerpc/cpu/mpc85xx/speed.c
+++ b/arch/powerpc/cpu/mpc85xx/speed.c
@@ -1,5 +1,5 @@
/*
- * Copyright 2004, 2007-2010 Freescale Semiconductor, Inc.
+ * Copyright 2004, 2007-2011 Freescale Semiconductor, Inc.
*
* (C) Copyright 2003 Motorola Inc.
* Xianghua Xiao, (x.x...@motorola.com)
@@ -131,7 +131,9 @@ void get_sys_info (sys_info_t * sysInfo)
#else
uint plat_ratio,e500_ratio,half_freqSystemBus;
+#if defined(CONFIG_FSL_LBC)
uint lcrr_div;
+#endif
int i;
#ifdef CONFIG_QE
u32 qe_ratio;
@@ -168,6 +170,7 @@ void get_sys_info (sys_info_t * sysInfo)
sysInfo->freqQE = qe_ratio * CONFIG_SYS_CLK_FREQ;
#endif
+#if defined(CONFIG_FSL_LBC)
#if defined(CONFIG_SYS_LBC_LCRR)
/* We will program LCRR to this value later */
lcrr_div = CONFIG_SYS_LBC_LCRR & LCRR_CLKDIV;
@@ -193,6 +196,7 @@ void get_sys_info (sys_info_t * sysInfo)
/* In case anyone cares what the unknown value is */
sysInfo->freqLocalBus = lcrr_div;
}
+#endif
}
--
1.6.5.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/7] mxc_i2c: Add support for the i.MX35 processor
Dear Stefano Babic, In message <1295012124-15551-3-git-send-email-sba...@denx.de> you wrote: > Signed-off-by: Stefano Babic Add a "Cc: Heiko Schocher " here so the responsible custodian is on Cc: > -#error "define CONFIG_SYS_I2C_MX31_PORTx to use the mx31 I2C driver" > +#error "define CONFIG_SYS_I2C_MXXX_PORTx to use the mx I2C driver" Please make this "CONFIG_SYS_I2C_MXxx_PORTx" or similar; text containing "XXX" triggers some spam filters. Yes, really! 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 only way to get rid of a temptation is to yield to it. - Oscar Wilde ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/7] Add support for MX35 processor
Dear Stefano Babic,
In message <1295012124-15551-1-git-send-email-sba...@denx.de> you wrote:
> The patch adds basic support for the Freescale's i.MX35
> (arm1136 based) processor.
>
> Signed-off-by: Stefano Babic
...
> +u32 get_cpu_rev(void)
> +{
> + int reg;
> + struct iim_regs *iim =
> + (struct iim_regs *)IIM_BASE_ADDR;
> + reg = readl(&iim->iim_srev);
> + if (!reg) {
> + reg = __REG(ROMPATCH_REV);
__REG()?
NAK. Please use I/O accessors. Please fix globally.
> +void imx_get_mac_from_fuse(unsigned char *mac)
> +{
> + int i;
> +
> + for (i = 0; i < 6; i++)
> + mac[i] = 0;
memset(mac, 0, 6);
?
> +/*
> + * IOMUX register (base) addresses
> + */
> +enum iomux_reg_addr {
> + IOMUXGPR = IOMUXC_BASE_ADDR,
> + /*!< General purpose */
> + IOMUXSW_MUX_CTL = IOMUXC_BASE_ADDR + 4,
> + /*!< MUX control */
> + IOMUXSW_MUX_END = IOMUXC_BASE_ADDR + 0x324,
> + /*!< last MUX control register */
> + IOMUXSW_PAD_CTL = IOMUXC_BASE_ADDR + 0x328,
> + /*!< Pad control */
> + IOMUXSW_PAD_END = IOMUXC_BASE_ADDR + 0x794,
> + /*!< last Pad control register */
> + IOMUXSW_INPUT_CTL = IOMUXC_BASE_ADDR + 0x7AC,
> + /*!< input select register */
> + IOMUXSW_INPUT_END = IOMUXC_BASE_ADDR + 0x9F4,
> + /*!< last input select register */
> +};
What do these "!<" markers mean?
> +/*
> + * This function is used to configure a pin through the IOMUX module.
> + * FIXED ME: for backward compatible. Will be static function!
> + * @param pin a pin number as defined in \b #iomux_pin_name_t
> + * @param cfg an output function as defined in \b
> #iomux_pin_cfg_t
> + *
> + * @return 0 if successful; Non-zero otherwise
When does the "otherwise" happen?
> + */
> +static int iomux_config_mux(iomux_pin_name_t pin, iomux_pin_cfg_t cfg)
> +{
> + u32 mux_reg = PIN_TO_IOMUX_MUX(pin);
> +
> + if (mux_reg != NON_MUX_I) {
> + mux_reg += IOMUXGPR;
> + __REG(mux_reg) = cfg;
> + }
> +
> + return 0;
> +}
Should we make this function return "void" ?
> +/* delay x useconds AND perserve advance timstamp value */
> +/* GPTCNT is now supposed to tick 1 by 1 us. */
s/perserve/preserve/ ?
Incorrect multiline comment style.
> diff --git a/arch/arm/include/asm/arch-mx35/imx-regs.h
> b/arch/arm/include/asm/arch-mx35/imx-regs.h
> new file mode 100644
> index 000..f382960
> --- /dev/null
> +++ b/arch/arm/include/asm/arch-mx35/imx-regs.h
...
> +#define __REG(x) (*((volatile u32 *)(x)))
> +#define __REG16(x) (*((volatile u16 *)(x)))
> +#define __REG8(x)(*((volatile u8 *)(x)))
NAK!! Please use I/O accessors. Please fix globally.
> +/* CCM */
> +#define CLKCTL_CCMR 0x00
> +#define CLKCTL_PDR0 0x04
> +#define CLKCTL_PDR1 0x08
> +#define CLKCTL_PDR2 0x0C
> +#define CLKCTL_PDR3 0x10
> +#define CLKCTL_PDR4 0x14
> +#define CLKCTL_RCSR 0x18
> +#define CLKCTL_MPCTL 0x1C
> +#define CLKCTL_PPCTL 0x20
> +#define CLKCTL_ACMR 0x24
> +#define CLKCTL_COSR 0x28
> +#define CLKCTL_CGR0 0x2C
> +#define CLKCTL_CGR1 0x30
> +#define CLKCTL_CGR2 0x34
> +#define CLKCTL_CGR3 0x38
NAK!! Please use C struct. Please fix globally.
> +#if 0
> +extern unsigned int mxc_get_clock(enum mxc_clock clk);
> +#endif
Please remove such dead code. Please fix globally.
> +extern unsigned int get_board_rev(void);
> +extern int is_soc_rev(int rev);
> +extern int sdhc_init(void);
> +
> +#define fixup_before_linux \
> + { \
> + volatile unsigned long *l2cc_ctl = (unsigned long *)0x3100;\
0x3100 ? Don't we have a #define for it?
> +/*
> + * The code contained herein is licensed under the GNU General Public
> + * License. You may obtain a copy of the GNU General Public License
> + * Version 2 or later at the following locations:
Please fix these license headers - all of these. They say where you
can _get_ License Version 2 or later, but they don't say which version
actually applies. Please make clear that License v2+ applies.
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
By the way, ALL software projects are done by iterative prototyping.
Some companies call their prototypes "releases", that's all.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/7] serial_mxc: add support for Freescale's i.MX35 processor
Dear Stefano Babic, In message <1295012124-15551-2-git-send-email-sba...@denx.de> you wrote: > The patch adds UART support for the i.MX35 processor. > > Signed-off-by: Stefano Babic > --- > drivers/serial/serial_mxc.c |4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/serial/serial_mxc.c b/drivers/serial/serial_mxc.c > index f96b21f..2dcae40 100644 > --- a/drivers/serial/serial_mxc.c > +++ b/drivers/serial/serial_mxc.c > @@ -50,9 +50,9 @@ > #define UART_PHYS 0x1001b000 > #elif defined(CONFIG_SYS_MX27_UART6) > #define UART_PHYS 0x1001c000 > -#elif defined(CONFIG_SYS_MX51_UART1) > +#elif defined(CONFIG_SYS_MX51_UART1) || defined(CONFIG_SYS_MX35_UART1) > #define UART_PHYS UART1_BASE_ADDR > -#elif defined(CONFIG_SYS_MX51_UART2) > +#elif defined(CONFIG_SYS_MX51_UART2) || defined(CONFIG_SYS_MX35_UART2) Please sort entries - CONFIG_SYS_MX35_UART2 goes before CONFIG_SYS_MX51_UART2. 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 in this world constant but inconstancy. - Swift ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] xilinx_ppc_boards: Change address of RESET_VECTOR
Dear Ricardo Ribalda Delgado, In message <1294823682-12502-1-git-send-email-ricardo.riba...@gmail.com> you wrote: > Old address of RESET_VECTOR were overwritten by the bss sector, making > impossible its run from xmd. > > Signed-off-by: Ricardo Ribalda Delgado I would like to minimize the configuration information present in boards.cfg; the current state resulted just from the attempt to minimize changes when converting to from Makefile to boards.cfg, but that should not be the final state. When you touch all of this anyway (and re-test it, obviously), can you then please take the chance and move all tis stuff from boards.cfg into your respective board config files, where it aktucally belongs? 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 The best things in life are for a fee. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] environmental "baudrate" not used at boot up
Dear chr...@cyberswitching.com,
In message <20110119053445.GA9776@cslinux-build01.cyberswitching.local> you
wrote:
>
> I investigated this a little further, and I'm wondering if the problem
> is related to the initialization ordering in lib_arm/board.c.
>
> Here's the sequence:
>
>start_armboot():
>1. init_baudrate() -> getenv_r() -> serial_setbrg()
>2. env_relocate()
>
> Note that init_baudrate() calls getenv_r("baudrate") and passes either
> the result (on success) or CONFIG_BAUDRATE (on error) to
> serial_setbrg(). Only after this does the environment get relocated
> using env_relocate().
Right. This is the intended sequence.
> Based on empirical testing, I've discovered that re-running
> init_baudrate() after env_relocate() fixes everything. The serial
> console uses the baud rate stored in the "baudrate" variable now, and
> some ordering of display outputs needs to be tweaked so that gibberish
> isn't output in the interim.
You have diagnosed where the problem is, but you come to the wrong
conclusions and instead of fixing the problem you paint over it.
Obviously getenv_r("baudrate") is not returning the right value for
you.
You should first check, what exactly it returns.
Then you should check why it is not reading the correct data, as it is
supposed to do.
Then you should fix _that_ problem.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
> Is there a way to determine Yesterday's date using Unix utilities?
echo "what is yesterday's date?" | /bin/mail root
-- Randal L. Schwartz in
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] environmental "baudrate" not used at boot up
On Sun, Jan 16, 2011 at 06:01:22AM -0800, chr...@cyberswitching.com wrote:
> ...
> Any advice on where to take it from here?
Hi everyone,
I investigated this a little further, and I'm wondering if the problem
is related to the initialization ordering in lib_arm/board.c.
Here's the sequence:
start_armboot():
1. init_baudrate() -> getenv_r() -> serial_setbrg()
2. env_relocate()
Note that init_baudrate() calls getenv_r("baudrate") and passes either
the result (on success) or CONFIG_BAUDRATE (on error) to
serial_setbrg(). Only after this does the environment get relocated
using env_relocate().
Based on empirical testing, I've discovered that re-running
init_baudrate() after env_relocate() fixes everything. The serial
console uses the baud rate stored in the "baudrate" variable now, and
some ordering of display outputs needs to be tweaked so that gibberish
isn't output in the interim.
The attached patch (below) should give a code-centric view. Please
ignore the minor style changes, as I was hacking code pretty feverishly
to try and figure this out. To be clear: DO NOT IMPORT THIS CODE
DIRECTLY INTO THE LATEST MASTER! It will need to be reviewed, tweaked,
and the finally imported by someone who knows more of what they are
doing than I. :-)
Hope this helps someone else out,
Chris
diff -p -r -U 3 a/drivers/mtd/nand/nand.c b/drivers/mtd/nand/nand.c
--- a/drivers/mtd/nand/nand.c 2009-01-21 14:08:12.0 -0800
+++ b/drivers/mtd/nand/nand.c 2011-01-18 21:29:36.0 -0800
@@ -57,6 +57,17 @@ static void nand_init_chip(struct mtd_in
}
+void display_nand_config(void)
+{
+ int i;
+ unsigned int size = 0;
+ printf("NAND: ");
+ for (i = 0; i < CONFIG_SYS_MAX_NAND_DEVICE; i++) {
+ size += nand_info[i].size / 1024;
+ }
+ printf("%u MiB\n", size / 1024);
+}
+
void nand_init(void)
{
int i;
@@ -67,7 +78,6 @@ void nand_init(void)
if (nand_curr_device == -1)
nand_curr_device = i;
}
- printf("%u MiB\n", size / 1024);
#ifdef CONFIG_SYS_NAND_SELECT_DEVICE
/*
diff -p -r -U 3 a/include/nand.h b/include/nand.h
--- a/include/nand.h2009-01-21 14:08:12.0 -0800
+++ b/include/nand.h2011-01-18 21:29:43.0 -0800
@@ -25,6 +25,7 @@
#define _NAND_H_
extern void nand_init(void);
+extern void display_nand_config(void);
#ifndef CONFIG_NAND_LEGACY
#include
diff -p -r -U 3 a/lib_arm/board.c b/lib_arm/board.c
--- a/lib_arm/board.c 2009-01-21 14:08:12.0 -0800
+++ b/lib_arm/board.c 2011-01-18 21:29:24.0 -0800
@@ -148,10 +148,15 @@ void inline yellow_LED_off(void)__attrib
static int init_baudrate (void)
{
char tmp[64]; /* long enough for environment variables */
- int i = getenv_r ("baudrate", tmp, sizeof (tmp));
- gd->bd->bi_baudrate = gd->baudrate = (i > 0)
- ? (int) simple_strtoul (tmp, NULL, 10)
- : CONFIG_BAUDRATE;
+ int i;
+ int baudrate = CONFIG_BAUDRATE;
+
+ i = getenv_r ("baudrate", tmp, sizeof (tmp));
+ if (i > 0)
+ baudrate = (int) simple_strtoul(tmp, NULL, 10);
+
+ gd->baudrate = baudrate;
+ gd->bd->bi_baudrate = baudrate;
return (0);
}
@@ -256,6 +261,14 @@ init_fnc_t *init_sequence[] = {
init_baudrate, /* initialze baudrate settings */
serial_init,/* serial communications setup */
console_init_f, /* stage 1 init of console */
+#if defined(CONFIG_HARD_I2C) || defined(CONFIG_SOFT_I2C)
+ init_func_i2c,
+#endif
+ dram_init, /* configure available RAM banks */
+ NULL,
+};
+
+init_fnc_t *display_sequence[] = {
display_banner, /* say that we are here */
#if defined(CONFIG_DISPLAY_CPUINFO)
print_cpuinfo, /* display cpu info (and speed) */
@@ -263,10 +276,9 @@ init_fnc_t *init_sequence[] = {
#if defined(CONFIG_DISPLAY_BOARDINFO)
checkboard, /* display board info */
#endif
-#if defined(CONFIG_HARD_I2C) || defined(CONFIG_SOFT_I2C)
- init_func_i2c,
+#if defined(CONFIG_CMD_NAND)
+ display_nand_config,
#endif
- dram_init, /* configure available RAM banks */
display_dram_config,
NULL,
};
@@ -340,7 +352,6 @@ void start_armboot (void)
mem_malloc_init (_armboot_start - CONFIG_SYS_MALLOC_LEN);
#if defined(CONFIG_CMD_NAND)
- puts ("NAND: ");
nand_init();/* go init the NAND */
#endif
@@ -396,6 +407,18 @@ void start_armboot (void)
#endif
}
+ /* Reinitialize the baud rate since the environment wasn't ready */
+ init_baudrate();
+ serial_setbrg();
+ udelay(5);
+
+ /* Now display the information to the serial console */
+ for (init_fnc_ptr = display_sequence; *init_fnc_ptr; ++init_fnc_ptr) {
+ if ((*init_fnc_ptr)() != 0) {
+
Re: [U-Boot] [PATCH] Net: Add Intel E1000 82574L PCIe card support
> -Original Message- > From: Wolfgang Denk [mailto:w...@denx.de] > Sent: Wednesday, January 19, 2011 6:33 AM > To: Zang Roy-R61911 > Cc: u-boot@lists.denx.de; Gala Kumar-B11780 > Subject: 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 > > --- [snip] > > 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 > >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 > > + * - Add PCI Express card support in Jul. 2009 > > + */ > > If you really insist on adding this, thenmove it up into the header. In fact, my original internal code put it to the header, but when I check it with checkpatch.pl, I will get a warning such as: WARNING: please, no spaces at the start of a line #156: FILE: drivers/net/e1000.h:5: + Copyright 2011 Freescale Semiconductor, Inc.$ How to balance? Thanks. Roy ___ 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 Wolfgang, On Wed, Jan 19, 2011 at 5:45 AM, Wolfgang Denk wrote: > Dear Po-Yu Chuang, > In message you > wrote: >> Would you please check this patch series? >> Or should I rebase and resubmit? > > This is mostly in the responsibility of Albert, the ARM custodian. Sorry, I didn't noticed that we have new custodian now. Thanks, Po-Yu Chuang ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Expert Beauty Magazine, UK & Europe - Spring 2011 and beyond - invitation
Hi there A (Belated) Happy New Year to you from all of us at Expert Beauty Magazine, UK & Europe. It is indeed our pleasure to invite your organisation to participate with advertising (and possibly editorial) for the Spring 2011 edition, deadline for which is rapidly approaching! Why would you want to advertise here? Started last year by renowned plastic surgeon, Charles Nduka, Expert Beauty Magazine features official and scientifically accurate information on surgical and non-surgical treatments, hair & make up, fashion, health, drugs and vitamins, fitness, and most other topics surrounding these issues. As an exclusive title, the magazine has been well received, and has already expanded to three times annually. It is distributed accordingly, with 25,000 copies per edition to be found at exclusive spas, fitness clubs, private hospital waiting areas, beauty salons, cosmetic dentists, hotels and business class airport lounges, thus reaching this wide and financially capable AB1 and high net worth demographic, c. 100,000 readers per edition. Thus, whether you are in the beauty/health industry or not, this is a remarkable vehicle to get your products and services infront of this lucrative potential customer base for your organisation. Interested? We would like to offer you a TRIAL ADVERTISING OFFER for the Spring Edition, as we hope you willl be back for more when you have seen the results! So, until 18:00 31st Jan 2011 we would like to offer you a full A4 page ad, with a free page editorial at just £1500.00 total (list price £3000.00), a half page ad at £750.00, or a quarter page at just £400.00 (usual media pack through links below)! To take advantage of this attractive offer while it is still here, simply reply to this email in the affirmative, together with your chosen ad size, to begin reaching this high net worth audience, and before 31 January please! We hope to be welcoming you to this exclusive publication very soon! Kind regards Sam Featherstone for EXPERT BEAUTY MAGAZINE T: +44 (0)845 428 9350 F: +44 (0)207 183 4752 W: www.expertbeauty.com Downloads Media kit: http://www.sksassociates.co.uk/eb/EBMediaPack2011.pdf Hotel Distribution: http://www.sksassociates.co.uk/eb/EB_Distribution_UKHotels.xls Medical Distribution: http://www.sksassociates.co.uk/eb/EB_Distribution_UKMedical.xls Contracted exclusively by: SKS/Enhanced Media & Communications Ltd 1 Farnham Road, Guildford, Surrey GU2 4RG UK ** You were subscribed to this offer list through one of our extensive, but discerning luxury partner networks. ** If you feel you have received this email in error, simply REPLY and SEND with the subject line intact. Thanks. <><>___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/4 v3] spi: add spi_set_speed func
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 --- v2 remove weak func as Mike suggested. v3 comment style fix as Wolfgang suggested. include/spi.h |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/include/spi.h b/include/spi.h index 320e50e..e364d2d 100644 --- a/include/spi.h +++ b/include/spi.h @@ -175,6 +175,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 + */ +void spi_set_speed(struct spi_slave *slave, uint hz); + /*--- * Write 8 bits, then read 8 bits. * slave:The SPI slave we're communicating with -- 1.7.3.4 ___ 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 11:53:38 pm Wolfgang Denk wrote: > Dear Marcel, > > In message <201101182337.32274.korg...@home.nl> you wrote: > > > 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. > > Come on. You will find a static array declaration when you know the > exact name of the file and the variable, right? Well finding it is not the issue. I can't find a reason why it wouldn't work. Regards, Marcel ___ 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 11:54:22 pm Reinhard Meyer wrote:
> 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
hmmm. What branch is best to work on for this code ?
> >>> req->buf = (u8 *) NetRxPackets[0];
>
> *maybe* "req" itself is not allocated?
Good question. My code that rejects the buffer is this :
static int
usba_ep_queue(struct usb_ep *_ep,
struct usb_request *_req,
gfp_t gfp_flags)
{
struct usba_request *req = container_of(_req, struct usba_request,
req);
struct usba_ep *ep = container_of(_ep, struct usba_ep, ep);
struct usba_udc *udc = ep->udc;
int ret;
debug("%s: queue req %p, len %u\n",
ep->ep.name, req, _req->length);
if (!_req || !_req->complete
|| !_req->buf || !list_empty(&req->queue)) {
DBG("invalid request\n");
if(!_req) debug("NO REQUEST\n");
if(!_req->complete) debug("NO REQUEST COMPLETE\n");
if(!_req->buf) debug("NO REQUEST BUF\n");
if(!list_empty(&req->queue)) debug("NO LIST EMPTY\n");
return -EINVAL;
}
It just keeps failing with "NO REQUEST BUF". I feel like I'm staring at a typo
for days and just don't see it.
regards,
Marcel
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[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
---
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
#include
+#include
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
[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 --- 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 palmtc xscale vpac270 xscale zipitz2 xscale + efikamx i.MX51 Hugo Villeneuve 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 +# +# BASED ON: imx51evk +# +# Copyright (C) 2007, Guennadi Liakhovetski +# +# (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 + * + * (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 the GNU General Public License + * along with this program; if not, write to
[U-Boot] [PATCH 1/3 v2] MC13892: Add SWx buck switchers definitions
Define voltages configurable on SWx buck switchers. Signed-off-by: Marek Vasut --- 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 2/3 RESEND] MX51EVK: Use SWx macros in PMIC init
Signed-off-by: Marek Vasut --- 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
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 > --- > 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
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 > --- > 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 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 > --- > 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] 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 > --- > 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] NetRxPackets
Dear Marcel, In message <201101182337.32274.korg...@home.nl> you wrote: > > > 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. Come on. You will find a static array declaration when you know the exact name of the file and the variable, right? 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 Status quo. Latin for "the mess we're in." ___ 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 > --- > 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 v2] Correct chip detect logic
Dear Yanjun Yang, In message you wrote: > The lan91c96_detect_chip routine is not correct according > to the manual. > > Signed-off-by: YanJun Yang > --- > 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] 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 > >> + * - 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 > 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] 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 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
[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
---
* 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 =
Re: [U-Boot] [PATCH 4/4] powerpc: Add LINK_OFF calls in early C-code.
Dear Joakim Tjernlund, In message 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
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 > --- > 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] 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 >> --- >> >> 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. >> * >> + * >> + * Copyright 2009, 2011 Freescale Semiconductor, Inc. >> + * Authors: Roy Zang >> + * - 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 >> 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 >> + * - 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 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 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 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 > --- > 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] 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 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 > --- > 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] [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 > 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 > Signed-off-by: Stefan Roese > cc: Wolfgang Denk > cc: Stefan Roese > cc: Werner Pfister > cc: Detlev Zundel 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] 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 > --- > > 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. > * > + * > + * Copyright 2009, 2011 Freescale Semiconductor, Inc. > + * Authors: Roy Zang > + * - 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 >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 > + * - 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 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 > > 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 > Acked-by: Heiko Schocher > > --- > 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 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 4/4] powerpc: Add LINK_OFF calls in early C-code.
Wolfgang Denk wrote on 2011/01/18 22:25:04: > > Dear Joakim Tjernlund, > > In message > 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] [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 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 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] [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 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 /config.h. > > This patch is tested with compilation for armada100 and guruplug. > > Signed-off-by: Lei Wen ... > +#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 v2 1/2] arm: a320 timer: move static data to global_data struct
Dear Po-Yu Chuang, In message you wrote: > > > From: Po-Yu Chuang > > > > 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] 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 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 V3] bugfix: image header pointer change.
Dear Baidu Boy, In message 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 4/4] powerpc: Add LINK_OFF calls in early C-code.
On Tue, 18 Jan 2011 21:39:23 +0100 Joakim Tjernlund wrote: > Scott Wood 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] 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.
Dear Joakim Tjernlund, In message 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] [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] 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.
Wolfgang Denk wrote on 2011/01/18 21:06:34: > Dear Joakim Tjernlund, > > In message > 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] [PATCH 1/3] MC13892: Add SWx buck switchers definitions
Hi, Marek, 2011/1/19 Marek Vasut : > Define voltages configurable on SWx buck switchers. > > Signed-off-by: Marek Vasut > --- > 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
[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
---
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;
+
Re: [U-Boot] [PATCH 4/4] powerpc: Add LINK_OFF calls in early C-code.
Scott Wood wrote on 2011/01/18 21:24:16: > On Tue, 18 Jan 2011 21:06:34 +0100 > Wolfgang Denk wrote: > > > Dear Joakim Tjernlund, > > > > In message > > > > 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
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 wrote: > Dear Joakim Tjernlund, > > In message > 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 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.
Dear Joakim Tjernlund, In message 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] [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] 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] [PATCH v4 7/8] imximage: Add MX53 boot image support
Dear Jason Liu,
In message 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] [PATCH 4/4] powerpc: Add LINK_OFF calls in early C-code.
Scott Wood wrote on 2011/01/18 18:27:49: > On Tue, 18 Jan 2011 01:18:34 +0100 > Joakim Tjernlund 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 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 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
[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 --- 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 palmtc xscale vpac270 xscale zipitz2 xscale + efikamx i.MX51 Hugo Villeneuve 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 +# +# BASED ON: imx51evk +# +# Copyright (C) 2007, Guennadi Liakhovetski +# +# (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 + * + * (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 the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Templ
[U-Boot] [PATCH 2/3] MX51EVK: Use SWx macros in PMIC init
Signed-off-by: Marek Vasut --- 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] MC13892: Add SWx buck switchers definitions
Define voltages configurable on SWx buck switchers. Signed-off-by: Marek Vasut --- 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
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 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
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
> ---
> 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] 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
> ---
> 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: 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 > --- > 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] 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
> ---
> 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] [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] [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
[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
---
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] [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 > --- > > 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 - k ___ 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 V2 2/2] SPI: mxc_spi: add SPI clock calculation and setup to the driver
Hello. Stefano Babic wrote: > From: Anatolij Gustschin > 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 > Signed-off-by: Stefano Babic WBR, Sergei ___ 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 v4 7/8] imximage: Add MX53 boot image support
Hi, Wolfgang,
2011/1/18 Wolfgang Denk :
> Dear Jason Liu,
>
> In message <1294129662-680-7-git-send-email-r64...@freescale.com> you wrote:
>> 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
> ...
>> static table_entry_t imximage_cmds[] = {
>> + {CMD_IMAGE_VERSION, "IMAGE_VERSION", "image 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?
>
>> {-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,58 +85,264 @@ static uint32_t get_cfg_value(char *token, char *name,
>> int linenr)
>> return value;
>> + /* Try to detect V1 */
>> + if (fhdr_v1->app_code_barker == APP_CODE_BARKER &&
>> + imx_hdr->header.hdr_v1.dcd_table.preamble.barker == DCD_BARKER)
>> +
>> + return IMXIMAGE_V1;
>
> This needs braces. Please fix globally.
>
>> +static void set_dcd_rst_v1(struct imx_header *imxhdr, uint32_t dcd_len,
>> + char *name, int lineno)
>
> Could you please add a comment what the somewhat cryptic name
> "set_dcd_rst_v1" is supposed to mean? Similar for the other functions
> like set_dcd_rst_v2() etc.?
OK, I will add some comments for this function.
>
>> + 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);
>> + }
>> +
>> + dcd_v1->preamble.barker = DCD_BARKER;
>> + dcd_v1->preamble.length = dcd_len * sizeof(dcd_type_addr_data_t);
>> +}
>
> It seems these functions can run into error situations - yet they are
> of type void, i. e. they don't return any information about such
> errors to their callers. In the end, you cannot test the result oif
> running the command to find out if it had worked or not.
>
> This must be fixed (globally).
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);
}
dcd_v1->preamble.barker = DCD_BARKER;
dcd_v1->preamble.length = dcd_len * sizeof(dcd_type_addr_data_t);
}
>
>
>> + case CMD_IMAGE_VERSION:
>> + imximage_version =
>> + get_cfg_value(token,
>> + name, lineno);
>> + if (cmd_ver_first == 0) {
>> + fprintf(stderr,
>> + "Error: %s[%d] - "
>> + "IMAGE_VERSION command
>> "
>> + "need appear the first
>> "
>> + "before other valid "
>> + "command in the
>> file\n",
>> + name, lineno);
>> + exit(EXIT_FAILURE);
>> + }
>
> Your nesting is too deep. Consider reorganizing the code.
In fact, I did not change the nesting deep, which is the same deep as
the original code,
I will reorganizing it.
>
>
> Stefano, Albert - I apologize for the late review. Please don't pull
> this into mainline as is.
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
___
U-Boot
Re: [U-Boot] [PATCH v4 7/8] imximage: Add MX53 boot image support
Hi, Wolfgang, 2011/1/18 Wolfgang Denk : > Dear Jason Liu, > > In message 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
Dear Jason Liu, In message 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 and Stefano, 2011/1/18 Wolfgang Denk : > 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] 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
[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] 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
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
[U-Boot] [PATCH v3] ppc, 8xx: remove obsolete km8xx boards from keymile
From: Holger Brunck
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
Acked-by: Heiko Schocher
---
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
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
-#include
-#include
-#include
-
-#if defined(CONFIG_OF_BOARD_SETUP) && defined(CONFIG_OF_LIBFDT)
-#include
-#endif
-
-#include "../common/common.h"
-
-DECLARE_GLOBAL_DATA_PTR;
-
-const uint sdram_table[] =
-{
- 0x0f07fc04, 0x0c04, 0x00bdfc04, 0x0ff77c00,
- 0x1c05, 0xfc04, 0xf
[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
---
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.
*
+ *
+ * Copyright 2009, 2011 Freescale Semiconductor, Inc.
+ * Authors: Roy Zang
+ * - 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)
+ match = TRUE;
+
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/.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 V2 2/2] SPI: mxc_spi: add SPI clock calculation and setup to the driver
From: Anatolij Gustschin
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
Signed-off-by: Stefano Babic
---
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
@@ -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] [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 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 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
