[U-Boot] ppc4xx PPC460EX DDR2 Autocalibration errata
Today I received an erratum fro apm that seems to claim that ddr2 autocalibration is not working properly on our 460EX boards. Is anyone already working on this? Would ddr_scan_option be the way to fix this? Or should 4xx_ibm_ddr2_autocalib.c generally be fixed for 460EX? Cheers Dirk DDR_2: Internal Timing violation for certain write data paths. Category: 3 Overview: Due to an internal timing violation, write data errors are possible with the following MCIF0_WRDTR[WDTR] settings: * 000 (270 degree advance) * 010 (90 degree advance) * 101 (180 degree delay) * 110 (270 degree delay) Notes: 1. This erratum does not affect the following MCIF0_WRDTR[WDTR] settings: * 001 (180 degree advance) * 011 (0 degree advance) * 100 (90 degree delay) 2. The timing error is internal. Write errors are possible even when the external timing appears to be valid. Impact: In some cases, the memory controller fails to calibrate or pass memory tests with MCIF0_WRDTR[WDTR] set to the 000, 010, 101, or 110 settings. Regardless of calibration or memory test results, write data errors are still possible with these settings. Workaround: For coarse write data/DQS/DM advance or delay, only use MCIF0_WRDTR[WDTR]=001 (180 degree advance), 011 (0 degree advance), or 100 (90 degree delay) settings. Use the fractional fine delay MCIF0_WRDTR[WDFD] to fine tune the delay for the Write data. * For 90 degree advance, set MCIF0_WRDTR[WDTR]=001 (180 degree advance) and MCIF0_WRDTR[WDFD]=0x3F (90 degree delay). * For 180 degree delay, set MCIF0_WRDTR[WDTR]=100 (90 degree delay) and MCIF0_WRDTR[WDFD]=0x3F (90 degree delay). There are no alternative configurations for 270 degree advance or 270 degree delay. Contact AppliedMicro technical support at supp...@apm.com for updated U-Boot software. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH ATMEL REWORK] update arm/at91rm9200 work with rework rework110202
Dear Jens Scharsig, Am 10.02.2011 um 20:31 schrieb Jens Scharsig: * update arm920t/at91 to ATMEL_xxx name scheme * convert at91rm9200ek and eb_cpux9k2 board to ATMEL_xxx name scheme * update arm920t/at91 soc lib * update at91_emac driver Signed-off-by: Jens Scharsig js_at...@scharsoft.de Tested-by: Andreas Bießmann andreas.de...@gmail.com But some changes --- The eb_cpux9k2 board can compile and runs after patch changes The at91rm9200ek can compile, but i have no hardware to test it. at91rm9200ek is working but the change for timer.c is needed Testet peripheral for at91rm9200ek is: - USB (fatls) - EMAC (tftp) arch/arm/cpu/arm920t/at91/reset.c |2 +- arch/arm/cpu/arm920t/at91/timer.c | 10 +- arch/arm/include/asm/arch-at91/at91_mc.h| 12 +- arch/arm/include/asm/arch-at91/at91_pmc.h | 10 +- arch/arm/include/asm/arch-at91/at91rm9200.h | 209 ++- board/BuS/eb_cpux9k2/cpux9k2.c | 52 board/atmel/at91rm9200ek/at91rm9200ek.c |4 +- board/atmel/at91rm9200ek/led.c | 22 ++-- drivers/net/at91_emac.c | 32 ++-- include/configs/at91rm9200ek.h |2 +- include/configs/eb_cpux9k2.h| 29 +++-- 11 files changed, 201 insertions(+), 183 deletions(-) [reset.c is OK] Please add: diff --git a/arch/arm/cpu/arm920t/at91/timer.c b/arch/arm/cpu/arm920t/at91/timer.c index e2630b8..f0ad7d6 100644 --- a/arch/arm/cpu/arm920t/at91/timer.c +++ b/arch/arm/cpu/arm920t/at91/timer.c @@ -32,7 +32,7 @@ #include common.h -#include asm/arch/io.h +#include asm/io.h #include asm/arch/hardware.h #include asm/arch/at91_tc.h #include asm/arch/at91_pmc.h [other changes to timer.c are OK] [at91_mc.h is OK] [at91_pmc.h is OK] diff --git a/arch/arm/include/asm/arch-at91/at91rm9200.h b/arch/arm/include/asm/arch-at91/at91rm9200.h index 1bee6f2..58f0e39 100644 --- a/arch/arm/include/asm/arch-at91/at91rm9200.h +++ b/arch/arm/include/asm/arch-at91/at91rm9200.h @@ -21,115 +21,126 @@ #ifndef __AT91RM9200_H__ #define __AT91RM9200_H__ +#define CONFIG_AT91FAMILY/* it's a member of AT91 */ +#define CONFIG_ARM920T /* This is an ARM920T Core */ + These are defined in board header .. I saw they are defined also in other at91xxx.h files, we should discuss where to define these since all of the at91xx.h files are included by hardware.h /* Periperial Identifiers */ [snip changes to at91rm9200.h which are obviously OK] +#define ATMEL_PIO_PORTS 4 /* theese SoCs have 3 PIO */ 3 or 4 PIO? +#define ATMEL_PMC_UHPAT91RM9200_PMC_UHP + +#define CONFIG_SYS_ATMEL_CPU_NAMEAT91RM9200 #endif [cpux9k2.c is OK] [at91rm9200ek.c is OK] [at91rm9200ek/led.c is OK] [at91_emac.c is OK] [at91rm9200ek.h is OK] --- a/include/configs/eb_cpux9k2.h +++ b/include/configs/eb_cpux9k2.h @@ -29,12 +29,13 @@ /*--*/ -#define CONFIG_ARM920T 1 /* This is an ARM920T Core */ -#define CONFIG_AT91RM92001 /* It's an Atmel AT91RM9200 SoC */ -#define CONFIG_EB_CPUX9K21 /* on an EP+CPUX9K2 Board */ -#define USE_920T_MMU 1 +#define CONFIG_ARM920T /* This is an ARM920T Core */ +#define CONFIG_AT91FAMILY +#define CONFIG_AT91RM9200/* It's an Atmel AT91RM9200 SoC */ +#define CONFIG_EB_CPUX9K2/* on an EP+CPUX9K2 Board */ +#define USE_920T_MMU -#define CONFIG_VERSION_VARIABLE 1 +#define CONFIG_VERSION_VARIABLE #define CONFIG_IDENT_STRINGon EB+CPUx9K2 #include asm/arch/hardware.h/* needed for port definitions */ @@ -186,8 +187,12 @@ #define CONFIG_NET_RETRY_COUNT10 #define CONFIG_RESET_PHY_R1 + please remove this additional empty line #define CONFIG_DRIVER_AT91EMAC1 #define CONFIG_DRIVER_AT91EMAC_QUIET 1 +/* +#define CONFIG_DRIVER_MACB 1 +*/ why this? Either it is needed or not. #define CONFIG_SYS_RX_ETH_BUFFER 8 #define CONFIG_MII1 @@ -217,19 +222,19 @@ #define CONFIG_SYS_I2C_INIT_BOARD #define I2C_INIT i2c_init_board(); -#define I2C_ACTIVE writel(AT91_PMX_AA_TWD, pio-pioa.mddr); -#define I2C_TRISTATE writel(AT91_PMX_AA_TWD, pio-pioa.mder); -#define I2C_READ ((readl(pio-pioa.pdsr) AT91_PMX_AA_TWD) != 0) +#define I2C_ACTIVE writel(ATMEL_PMX_AA_TWD, pio-pioa.mddr); +#define I2C_TRISTATE writel(ATMEL_PMX_AA_TWD, pio-pioa.mder); +#define I2C_READ ((readl(pio-pioa.pdsr) ATMEL_PMX_AA_TWD) != 0) #define I2C_SDA(bit) \ if (bit)\ - writel(AT91_PMX_AA_TWD, pio-pioa.sodr); \ + writel(ATMEL_PMX_AA_TWD, pio-pioa.sodr); \ else
Re: [U-Boot] BSS footprint of FAT very high - SPL issues
Le 11/02/2011 07:57, Aneesh V a écrit : As you point out, using __u_boot_cmd would cause as much of a concern as the current use of __bss_start, so I see no improvement there. Please define a label in the linker file. If you haven't got time to port the change to other linkers, don't ; the BSS issue is, for now, specific to your case. I thought it rather unlikely that the position of __u_boot_cmd will change in future. But I agree with you. Better do it cleanly once and for all. Changing the linker scripts for all cpus should not be a big deal. But I will not be able to test any of them except armv7/omap4 One patch will do, right? Yes. Also, any thoughts on the name for the new label. _end_of_relocated_image is all I can think of? Current practice has _end appended to whatever the labels delimit -- same as for _start. Besides, the relocated part would be inexact; what matters here is the loading, or copying, of the image, not its relocation (and actually BSS is kind-of-relocated, as references to BSS from text or data may be the target of a relocation record). So I would suggest __image_load_end or __image_copy_end. Best regards, Aneesh Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ppc4xx PPC460EX DDR2 Autocalibration errata
Hi Dirk, On Friday 11 February 2011 08:59:47 Eibach, Dirk wrote: Today I received an erratum fro apm that seems to claim that ddr2 autocalibration is not working properly on our 460EX boards. Is anyone already working on this? Not that I am aware of this. Perhaps somebody at AppliedMicro? Would ddr_scan_option be the way to fix this? Or should 4xx_ibm_ddr2_autocalib.c generally be fixed for 460EX? Yes, ddr_scan_option() can be used to supply a board specific fix. But a generic fix in 4xx_ibm_ddr2_autocalib.c would be much better of course. Do you experience any possible DDR2 related problems on your 460EX/GT based boards? Cheers, Stefan -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] BSS footprint of FAT very high - SPL issues
On Friday 11 February 2011 01:45 PM, Albert ARIBAUD wrote: [snip..] Also, any thoughts on the name for the new label. _end_of_relocated_image is all I can think of? Current practice has _end appended to whatever the labels delimit -- same as for _start. Besides, the relocated part would be inexact; what matters here is the loading, or copying, of the image, not its relocation (and actually BSS is kind-of-relocated, as references to BSS from text or data may be the target of a relocation record). So I would suggest __image_load_end or __image_copy_end. Thanks. I will go with __image_copy_end Best regards, Aneesh Amicalement, ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ppc4xx PPC460EX DDR2 Autocalibration errata
Hi Dirk, Hi Stefan, On Friday 11 February 2011 08:59:47 Eibach, Dirk wrote: Today I received an erratum fro apm that seems to claim that ddr2 autocalibration is not working properly on our 460EX boards. Is anyone already working on this? Not that I am aware of this. Perhaps somebody at AppliedMicro? They offer an updated u-boot in the errata ... Would ddr_scan_option be the way to fix this? Or should 4xx_ibm_ddr2_autocalib.c generally be fixed for 460EX? Yes, ddr_scan_option() can be used to supply a board specific fix. But a generic fix in 4xx_ibm_ddr2_autocalib.c would be much better of course. That's what I thought. Do you experience any possible DDR2 related problems on your 460EX/GT based boards? None that I am aware of. But it sounds scary anyway ... Cheers, Stefan Cheers Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mkimage: add -V option to print version information
Signed-off-by: Wolfgang Denk w...@denx.de --- tools/mkimage.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/tools/mkimage.c b/tools/mkimage.c index f5859d7..788484d 100644 --- a/tools/mkimage.c +++ b/tools/mkimage.c @@ -23,6 +23,7 @@ #include mkimage.h #include image.h +#include version.h static void copy_file(int, const char *, int); static void usage(void); @@ -246,6 +247,10 @@ main (int argc, char **argv) case 'v': params.vflag++; break; + case 'V': + printf(mkimage version %s\n, + U_BOOT_VERSION + 7); + exit(EXIT_SUCCESS); case 'x': params.xflag++; break; @@ -590,6 +595,7 @@ usage () params.cmdname); fprintf (stderr,%s [-D dtc_options] -f fit-image.its fit-image\n, params.cmdname); + fprintf (stderr,%s -V == print version information and exit\n); exit (EXIT_FAILURE); } -- 1.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] ARM: NVIDIA Tegra2 SoC support, running/flashing on Harmony
Hi Tom I am working with NVIDIA Harmony board and have chromium U-Boot 2009.11 working on it nicely after just changing the TEXT_BASE in board/tegra2/harmony/config.mk from 0x00e08000 to 0x00108000 as outlined in the NVIDIA developer forum. Now I saw your recent work on mainlining basic NVIDIA Tegra2 SoC support which is currently only available in the ARM U-Boot custodian tree at git://git.denx.de/u-boot-arm.git. I can compile it fine for Harmony but I have not figured out how one could get this one flashed onto the board. Can you quickly outline what tool you are using (e.g. vibrante burnflash, fastboot, nvflash or chromium burn-u-boot) and what the exact parameters thereof (e.g. load addresses and such) are? Thanks for your help! Cheers Marcel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MTD partitions not mounted by the kernel
Dear Alexandre Gambier, please do not top post / full quote; please read http://www.netmeister.org/news/learn2quote.html In message 4d54eb92.7080...@ftemaximal.fr you wrote: I will try to write my own driver for my board. You almost certainly do not have to write any new driver. You just need to configure the existing ones for your hardware. 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 (null cookie; hope that's ok) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM: NVIDIA Tegra2 SoC support, running/flashing on Harmony
Dear mar...@ziswiler.com, In message 421429519.780509.1297414600267.javamail.open-xcha...@oxusltgw06.schlund.de you wrote: I am working with NVIDIA Harmony board and have chromium U-Boot 2009.11 working on it nicely after just changing the TEXT_BASE in ... onto the board. Can you quickly outline what tool you are using (e.g. vibrante burnflash, fastboot, nvflash or chromium burn-u-boot) and what the exact parameters thereof (e.g. load addresses and such) are? You wroite that you have U-Boot running - then why do you not use U-Boot to bootstrap itself? That's always the most natural approach... 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] MTD partitions not mounted by the kernel
On 02/11/2011 10:06 AM, Wolfgang Denk wrote: Dear Alexandre Gambier, please do not top post / full quote; please read http://www.netmeister.org/news/learn2quote.html Sorry In message4d54eb92.7080...@ftemaximal.fr you wrote: I will try to write my own driver for my board. You almost certainly do not have to write any new driver. You just need to configure the existing ones for your hardware. Best regards, I will try to use physmap-flash for the NOR and gen_nand for the NAND. Wolfgang Denk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Networking problem with LAN8700 PHY at Cogent CSB737
Hello,
I'm trying to port U-Boot 2010.09 to Cogent CSB737 board. It has an
ATMEL At91SAM9263 uC and a SMSC LAN8700 PHY. U-Boot already runs quite
well, but with networking it has problems.
U-Boot detects the PHY and is able to send packages over LAN, but do not
receives any packages.
What could be the problem?
Thanks
Andreas Schimmel
Configs:
/* Ethernet */
#define CONFIG_MACB 1
#define CONFIG_RMII 1
#define CONFIG_NET_MULTI1
#define CONFIG_NET_RETRY_COUNT 20
#define CONFIG_RESET_PHY_R 1
Source File:
#include common.h
#include asm/sizes.h
#include asm/arch/at91sam9263.h
#include asm/arch/at91sam9_smc.h
#include asm/arch/at91_common.h
#include asm/arch/at91_pmc.h
#include asm/arch/at91_rstc.h
#include asm/arch/at91_matrix.h
#include asm/arch/at91_pio.h
#include asm/arch/clk.h
#include asm/arch/io.h
#include asm/arch/hardware.h
/*
#include lcd.h
#include atmel_lcdc.h
*/
#include dataflash.h
#if defined(CONFIG_RESET_PHY_R) defined(CONFIG_MACB)
#include net.h
#endif
#include netdev.h
DECLARE_GLOBAL_DATA_PTR;
#ifdef CONFIG_CMD_NAND
static void csb737_nand_hw_init(void)
{
unsigned long csa;
at91_smc_t *smc= (at91_smc_t *) AT91_SMC0_BASE;
at91_matrix_t *matrix = (at91_matrix_t *) AT91_MATRIX_BASE;
/* Enable CS3 */
csa = readl(matrix-csa[0]) | AT91_MATRIX_CSA_EBI_CS3A;
writel(csa, matrix-csa[0]);
/* Configure SMC CS3 for NAND/SmartMedia */
writel(AT91_SMC_SETUP_NWE(1) | AT91_SMC_SETUP_NCS_WR(1) |
AT91_SMC_SETUP_NRD(1) | AT91_SMC_SETUP_NCS_RD(1),
smc-cs[3].setup);
writel(AT91_SMC_PULSE_NWE(3) | AT91_SMC_PULSE_NCS_WR(3) |
AT91_SMC_PULSE_NRD(3) | AT91_SMC_PULSE_NCS_RD(3),
smc-cs[3].pulse);
writel(AT91_SMC_CYCLE_NWE(5) | AT91_SMC_CYCLE_NRD(5),
smc-cs[3].cycle);
writel(AT91_SMC_MODE_RM_NRD | AT91_SMC_MODE_WM_NWE |
AT91_SMC_MODE_EXNW_DISABLE |
#ifdef CONFIG_SYS_NAND_DBW_16
AT91_SMC_MODE_DBW_16 |
#else /* CONFIG_SYS_NAND_DBW_8 */
AT91_SMC_MODE_DBW_8 |
#endif
AT91_SMC_MODE_TDF_CYCLE(2),
smc-cs[3].mode);
/* Configure RDY/BSY */
at91_set_pio_input(CONFIG_SYS_NAND_READY_PIN, 1);
/* Enable NandFlash */
at91_set_pio_output(CONFIG_SYS_NAND_ENABLE_PIN, 1);
}
#endif
#ifdef CONFIG_MACB
static void csb737_macb_hw_init(void)
{
unsigned long erstl;
at91_pmc_t *pmc= (at91_pmc_t *) AT91_PMC_BASE;
at91_pio_t *pio= (at91_pio_t *) AT91_PIO_BASE;
at91_rstc_t *rstc = (at91_rstc_t *) AT91_RSTC_BASE;
/*
* Disable pull-up on:
* RXDV (PC25) = PHY normal mode (not Test mode)
* ERX0 (PE25) = PHY ADDR0
* ERX1 (PE26) = PHY ADDR1 = PHYADDR = 0x0
*
* PHY has internal pull-down
*/
writel(1 25, pio-pioc.pudr);
writel((1 25) | (1 26), pio-pioe.pudr);
erstl = readl(rstc-mr) AT91_RSTC_MR_ERSTL_MASK;
/* Need to reset PHY - 500ms reset */
writel(AT91_RSTC_KEY | AT91_RSTC_MR_ERSTL(0x0D) |
AT91_RSTC_MR_URSTEN, rstc-mr);
writel(AT91_RSTC_KEY | AT91_RSTC_CR_EXTRST, rstc-cr);
/* Wait for end hardware reset */
while (!(readl(rstc-sr) AT91_RSTC_SR_NRSTL))
;
/* Restore NRST value */
writel(AT91_RSTC_KEY | erstl | AT91_RSTC_MR_URSTEN, rstc-mr);
udelay( 21 * 1000);
/* Re-enable pull-up */
writel(1 25, pio-pioc.puer);
writel((1 25) | (1 26), pio-pioe.puer);
/* Enable clock */
writel(1 AT91SAM9263_ID_EMAC, pmc-pcer);
at91_macb_hw_init();
}
#endif
int board_init(void)
{
/* Enable Ctrlc */
console_init_f();
/* arch number of CSB737-Board */
gd-bd-bi_arch_number = MACH_TYPE_CSB737;
/* adress of boot parameters */
gd-bd-bi_boot_params = PHYS_SDRAM + 0x100;
at91_serial_hw_init();
#ifdef CONFIG_CMD_NAND
csb737_nand_hw_init();
#endif
#ifdef CONFIG_HAS_DATAFLASH
at91_spi0_hw_init(1 0);
#endif
#ifdef CONFIG_MACB
csb737_macb_hw_init();
#endif
#ifdef CONFIG_USB_OHCI_NEW
at91_uhp_hw_init();
#endif
return 0;
}
int dram_init(void)
{
gd-bd-bi_dram[0].start = PHYS_SDRAM;
gd-bd-bi_dram[0].size = PHYS_SDRAM_SIZE;
return 0;
}
#ifdef CONFIG_RESET_PHY_R
void reset_phy(void)
{
}
#endif
int board_eth_init(bd_t *bis)
{
int rc = 0;
#ifdef CONFIG_MACB
rc = macb_eth_initialize(0, (void *) AT91_EMAC_BASE, 0x1F);
#endif
return rc;
}
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Networking problem with LAN8700 PHY at Cogent CSB737
Dear Andreas Schimmel, In message 1297416475.3514.24.camel@paul you wrote: I'm trying to port U-Boot 2010.09 to Cogent CSB737 board. It has an ATMEL At91SAM9263 uC and a SMSC LAN8700 PHY. U-Boot already runs quite well, but with networking it has problems. U-Boot detects the PHY and is able to send packages over LAN, but do not receives any packages. What could be the problem? It can of course be anything - broken hardware, invalid MAC address, software issues. Sorry, you don't provide any details, so we cannot even speculate. 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 hear an onion ring, answer it. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM: NVIDIA Tegra2 SoC support, running/flashing on Harmony
On 11 February 2011 at 10:11 Wolfgang Denk w...@denx.de wrote: You wroite that you have U-Boot running - then why do you not use U-Boot to bootstrap itself? That's always the most natural approach... Good point if there where any kind of NAND flash support on Harmony in U-Boot yet. But that's not the case. I do understand that this is all very early stuff but would like to help in testing/improving if possible. Cheers Marcel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] ARM: mx31pdk: Use the new relocation scheme
Hi Albert, On Wednesday 09 February 2011 02:20 AM, Albert ARIBAUD wrote: Le 08/02/2011 21:18, stefano babic a écrit : Am 08.02.2011 20:26, schrieb Magnus Lilja: Patch reposted as a separate mail a couple of minutes ago. As I mention in the patch I think Fabio's patch has to be applied first. I think your patch is ok - Fabio fixed the syntax error as you do. We need only one of them. Another solution would be to change my patch somewhat to apply it first and then update Fabios patch to only touch the i.MX31-PDK specific files. IMHO this is the preferred way, because the two issues are orthogonal. Your patch fixes booting from NAND for ARM11, and Fabio's patch fix the mx31pdk board only. Agreed. Note also that there was a recent patch to ARM926's start.S (replacing 'adr r1, _start' with 'ldr r1, _TEXT_BASE' at line 284). The same should be done on arm1136. Is this going to happen for armv7 too? What is the real reason behind this proposal. What is the case when _start is not same as _TEXT_BASE(I looked at the archives but couldn't filter out the original discussion on this) I see a problem with that. _TEXT_BASE is based on CONFIG_SYS_TEXT_BASE. In our SPL's case CONFIG_SYS_TEXT_BASE indicates the TEXT_BASE for u-boot and *CONFIG_SYS_SPL_TEXT_BASE* indicates the TEXT_BASE for SPL. Both are defined and useful in SPL because one is used for linking SPL while the other is used while loading u-boot from MMC. So, CONFIG_SYS_TEXT_BASE used in the start.S of SPL will not be correct. In the worst case we need to define yet another label in the linker scripts like __text_base. But I was wondering if we could maintain the status quo for armv7: that is 'adr r1, _start' Best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Trouble with U-Boot on our EVM-based hardware
Hi there, First of all I am new with xldr/uboot, but not new with OMAP3(EVM). Maybe this isn't the correct address, so please be kind with me, if not. Our hardware is based on the OMAP3EVM board, but with some changes. I got trouble with U-Boot, which forget configuration in the gd-bd-bi_dram[0].start and .size. Starting OS Bootloader from MMC by jumping to 0x80008000... U-Boot 2010.06 (Feb 11 2011 - 10:09:18) OMAP3430/3530-GP ES3.1, CPU-OPP2 L3-165MHz OMAP3 EVM board + LPDDR/NAND I2C: ready DRAM: 0 Bytes NAND: 256 MiB *** Warning - bad CRC or NAND, using default environment In:serial Out: serial Err: serial Die ID #415e0004040365fb16003015 Hit any key to stop autoboot: 0 OMAP3_EVM In cpu/arm_cortexa8/omap3/sdrc.c in function dram_init() this struct is set: gd-bd-bi_dram[0].start = PHYS_SDRAM_1; gd-bd-bi_dram[0].size = size0; gd-bd-bi_dram[1].start = PHYS_SDRAM_1 + get_sdr_cs_offset(CS1); gd-bd-bi_dram[1].size = size1; Sadly if I printf the gd-bd-bi_dram[0].start after this lines I got zero. So later with DRAM: (see bold log) he also can't get the values. Later If I want to start the kernel, the kernel is checked (and this common functions of lib/arm/bootm.c will store additional informations in this gd-struct, which also get lost. reading uImage 3143676 bytes read Booting from mmc ... ## Booting kernel from Legacy Image at 8000 ... Image Name: Angstrom/2.6.32/omap3evm Image Type: ARM Linux Kernel Image (uncompressed) Data Size:3143612 Bytes = 3 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK I don't get a starting kernel. If I change the struct definition in include/asm_arm/u-boot.h to volatile (for size/start/bi_dram), it works. My printf directly after the set in dram_init is ok, and he also know now, that we are using 256 MB Ram. At first I used the branch git://arago-project.org/git/projects/u-boot-omap3.git;protocol=git with revision 7683ca6af43c17cf8214e9a241cd63c0001a59b1 (labeled as OMAPPSP_03.00.01.06 from 19.10.2010) Now I use the current head revision from Arago-project (0231dc91cd52760fa5cf4209e37c7adb06305da7) from 19 Jan 2011. Same result. Also I tried the beagle variante as defined with SRC_URI_beagleboard in u-boot_git.bb in the current openembedded release (from git://www.denx.de/git/u-boot.git;protocol=git with revision ca6e1c136ddb720c3bb2cc043b99f7f06bc46c55 and a lot of patch files). Nothing changes. If I change more variables in other structs to volatile (global_data.h / setup.h), I got even the kernel to start. U-boot call the address, where he puts the kernel, but the kernel ends in a tiny loop, I can see it via jtag (want to have a 0x20 in R2). I don't get additional logger outputs like decompressing kernel or something which can help me. Maybe my kernel needs also some changes for our platform, but I can't change something more to volatile, which is only a quick ugly workaround to understand a little bit more. My ram settings are all correct - yes really, the hardware is ok (WinCE runs perfectly, and I use the same SDRC-registers). I can use the whole 0x8000 range. I can read the xldr/uboot/kernel from sdcard to memory, can transport it from memory to flash and omap can start from flash - so the ram generally is ok. But the *important* struct gd here does something really weird. The struct is created in lib_arm/board.c: /* Pointer is writable since we allocated a register for it */ gd = (gd_t*)(_armboot_start - CONFIG_SYS_MALLOC_LEN - sizeof(gd_t)); /* compiler optimization barrier needed for GCC = 3.4 */ __asm__ __volatile__(: : :memory); memset ((void*)gd, 0, sizeof (gd_t)); gd-bd = (bd_t*)((char*)gd - sizeof(bd_t)); memset (gd-bd, 0, sizeof (bd_t)); The position of gd is originally 0x80E3FFE0, but I also try different locations, i.e. 0x8F00. With JTAG I can see that he clear this position to zero (memset!), but no effect with the gd-bd-bi_dram[0].start. I set a jtag breakpoint to read/write this address, and got no call for write. Only a break on reading this zero. Maybe our compiler does something really weird: arm-angstrom-linux-gnueabi-gcc (GCC) 4.5.3 20110110 (prerelease) Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. I also tried to change the compiler flags (from optimisation -Os to -O0 or -O1), but no change. I also found a chatlog http://www.beagleboard.org/irclogs/index.php?date=2010-11-22 where the user dent_ (scroll to end) has the same problem. He try an older gcc (which I am try at next), but what is the reason here? What is going on here? Can somebody help me understanding this? Best regards, David. ___ David
[U-Boot] [PATCH v2] mkimage: add -V option to print version information
Signed-off-by: Wolfgang Denk w...@denx.de --- v2: fix missing argument to printf() call. tools/mkimage.c |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/tools/mkimage.c b/tools/mkimage.c index f5859d7..127be57 100644 --- a/tools/mkimage.c +++ b/tools/mkimage.c @@ -23,6 +23,7 @@ #include mkimage.h #include image.h +#include version.h static void copy_file(int, const char *, int); static void usage(void); @@ -246,6 +247,10 @@ main (int argc, char **argv) case 'v': params.vflag++; break; + case 'V': + printf(mkimage version %s\n, + U_BOOT_VERSION + 7); + exit(EXIT_SUCCESS); case 'x': params.xflag++; break; @@ -590,6 +595,8 @@ usage () params.cmdname); fprintf (stderr,%s [-D dtc_options] -f fit-image.its fit-image\n, params.cmdname); + fprintf (stderr,%s -V == print version information and exit\n, + params.cmdname); exit (EXIT_FAILURE); } -- 1.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] ARM: mx31pdk: Use the new relocation scheme
Le 11/02/2011 11:51, Aneesh V a écrit : Hi Albert, On Wednesday 09 February 2011 02:20 AM, Albert ARIBAUD wrote: Le 08/02/2011 21:18, stefano babic a écrit : Am 08.02.2011 20:26, schrieb Magnus Lilja: Patch reposted as a separate mail a couple of minutes ago. As I mention in the patch I think Fabio's patch has to be applied first. I think your patch is ok - Fabio fixed the syntax error as you do. We need only one of them. Another solution would be to change my patch somewhat to apply it first and then update Fabios patch to only touch the i.MX31-PDK specific files. IMHO this is the preferred way, because the two issues are orthogonal. Your patch fixes booting from NAND for ARM11, and Fabio's patch fix the mx31pdk board only. Agreed. Note also that there was a recent patch to ARM926's start.S (replacing 'adr r1, _start' with 'ldr r1, _TEXT_BASE' at line 284). The same should be done on arm1136. Is this going to happen for armv7 too? What is the real reason behind this proposal. What is the case when _start is not same as _TEXT_BASE(I looked at the archives but couldn't filter out the original discussion on this) The difference is that _TEXT_BASE always contains the link-time address of _start, whereas references to _start may contain a different value if the code is executed somewhere else than at the link-time address. /Normally/, u-boot should always execute first at the link-time address -- that's a base constraint. /But/ this change makes it more resilient to out-of-link-time-address execution, and I want, at some time in the future, to find a way for u-boot to be able to start anywhere -- within reasonable limits: anywhere in NOR for a NOR-based U-boot, anywhere in RAM for a RAM-based U-boot, but I am not talking about a generic, run-in-RAM-or-NOR-or-anywhere, binary. Yet. :) I see a problem with that. _TEXT_BASE is based on CONFIG_SYS_TEXT_BASE. In our SPL's case CONFIG_SYS_TEXT_BASE indicates the TEXT_BASE for u-boot and *CONFIG_SYS_SPL_TEXT_BASE* indicates the TEXT_BASE for SPL. Both are defined and useful in SPL because one is used for linking SPL while the other is used while loading u-boot from MMC. So, CONFIG_SYS_TEXT_BASE used in the start.S of SPL will not be correct. The change I indicate is under the #else of a #ifdef CONFIG_NAND_SPL, so it will not apply to SPL. Does that still cause an issue with armv7? In the worst case we need to define yet another label in the linker scripts like __text_base. But I was wondering if we could maintain the status quo for armv7: that is 'adr r1, _start' As long as you run the u-boot start code at the link-time address, there will be no difference except the code is more correct with respect to what it should do; and if you run it elsewhere, which you should not, you have slightly better chances that it manages to survive. Best regards, Aneesh Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] unzip: return uncompressed size in `filesize', and print it.
The unzip command did not provide a way for the caller to get any
information about the uncompressed size. To make it better usable in
scripts, we now store the uncompressed size in the `filesize'
variable, like we do when for example loading a file over the network
or when reading it from a file system. Following that analogy, it is
only consequent to also print the size.
Signed-off-by: Wolfgang Denk w...@denx.de
---
common/cmd_mem.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/common/cmd_mem.c b/common/cmd_mem.c
index ccf420a..54e581a 100644
--- a/common/cmd_mem.c
+++ b/common/cmd_mem.c
@@ -1212,6 +1212,8 @@ int do_unzip ( cmd_tbl_t *cmdtp, int flag, int argc, char
* const argv[])
{
unsigned long src, dst;
unsigned long src_len = ~0UL, dst_len = ~0UL;
+ int rc;
+ char buf[32];
switch (argc) {
case 4:
@@ -1225,7 +1227,13 @@ int do_unzip ( cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
return cmd_usage(cmdtp);
}
- return !!gunzip((void *) dst, dst_len, (void *) src, src_len);
+ rc = gunzip((void *) dst, dst_len, (void *) src, src_len);
+
+ printf(Uncompressed size: %ld = 0x%lX\n, src_len, src_len);
+ sprintf(buf, %lX, src_len);
+ setenv(filesize, buf);
+
+ return !!rc;
}
#endif /* CONFIG_CMD_UNZIP */
--
1.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] ARM: mx31pdk: Use the new relocation scheme
On Friday 11 February 2011 06:16 PM, Albert ARIBAUD wrote: [snip...] Note also that there was a recent patch to ARM926's start.S (replacing 'adr r1, _start' with 'ldr r1, _TEXT_BASE' at line 284). The same should be done on arm1136. Is this going to happen for armv7 too? What is the real reason behind this proposal. What is the case when _start is not same as _TEXT_BASE(I looked at the archives but couldn't filter out the original discussion on this) The difference is that _TEXT_BASE always contains the link-time address of _start, whereas references to _start may contain a different value if the code is executed somewhere else than at the link-time address. /Normally/, u-boot should always execute first at the link-time address -- that's a base constraint. /But/ this change makes it more resilient to out-of-link-time-address execution, and I want, at some time in the future, to find a way for u-boot to be able to start anywhere -- within reasonable limits: anywhere in NOR for a NOR-based U-boot, anywhere in RAM for a RAM-based U-boot, but I am not talking about a generic, run-in-RAM-or-NOR-or-anywhere, binary. Yet. :) I see a problem with that. _TEXT_BASE is based on CONFIG_SYS_TEXT_BASE. In our SPL's case CONFIG_SYS_TEXT_BASE indicates the TEXT_BASE for u-boot and *CONFIG_SYS_SPL_TEXT_BASE* indicates the TEXT_BASE for SPL. Both are defined and useful in SPL because one is used for linking SPL while the other is used while loading u-boot from MMC. So, CONFIG_SYS_TEXT_BASE used in the start.S of SPL will not be correct. The change I indicate is under the #else of a #ifdef CONFIG_NAND_SPL, so it will not apply to SPL. Does that still cause an issue with armv7? No. It doesn't. I am fine with this change if it applies only to u-boot. br, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] u-boot sparc for leon3-altera-ep2s60-sdr working
Hi guys, I'd like to add the configuration for leon3-altera-ep2s60-sdr board. What could be the best working way to have an automatic patch generator? Thanks Fabio Giovagnini ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] P2020 SPL L2 clearing
2. Why does the cache to be cleared at all? L2-SRAM is usually just used to copy in the second part of the u-boot image, so the 0s will be overwritten again anyway. This needs to be done because we enable ECC. I'm still trying to get my head around this. From looking at the code this doesn't seem to be necessary. The ECC errors are disabled before L2 is configured as SRAM: cpu_init_f (NAND) /* set MBECCDIS=1, SBECCDIS=1 */ out_be32(l2cache-l2errdis, (MPC85xx_L2ERRDIS_MBECC | MPC85xx_L2ERRDIS_SBECC)); /* set L2E=1 L2SRAM=001 */ out_be32(l2cache-l2ctl, (MPC85xx_L2CTL_L2E | MPC85xx_L2CTL_L2SRAM_ENTIRE)); And these ECC disable bits are only cleared once the u-boot has already been copied to RAM and L2 is really used as cache: cpu_init_r /* set MBECCDIS=0, SBECCDIS=0 */ clrbits_be32(l2cache-l2errdis, (MPC85xx_L2ERRDIS_MBECC | MPC85xx_L2ERRDIS_SBECC)); So am I getting something wrong? Thanks bye Fabi ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] cfi_flash: use AMD fixups for AMIC (e.g. A29L160A series) too
Signed-off-by: Mario Schuknecht m.schukne...@dresearch.de
Signed-off-by: Steffen Sledz sl...@dresearch.de
---
drivers/mtd/cfi_flash.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
index dd394a8..527a3a5 100644
--- a/drivers/mtd/cfi_flash.c
+++ b/drivers/mtd/cfi_flash.c
@@ -1924,7 +1924,8 @@ ulong flash_get_size (phys_addr_t base, int banknum)
/* Do manufacturer-specific fixups */
switch (info-manufacturer_id) {
- case 0x0001:
+ case 0x0001: /* AMD */
+ case 0x0037: /* AMIC */
flash_fixup_amd(info, qry);
break;
case 0x001f:
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-BOOT] [PATCH] mmc: enable switch partition function
I am thinking now approach for this. How about adding addtitional member in the mmc structure, like part. During mmc probe, the driver could know whether the device support partition switch or not, if it support, we could register three other faked mmc device corresponding to two boot partition, and RPMB partition. Then we could use the current command to access the different hardware partition in the emmc. Like if we are accessing one hardware partition, we need to send switch command first. If the part member in the mmc is a invalid value, we then don't send that switch partition command. Could this approach be acceptable? Further refine this idea, don't need to call mmc_register multi-times. For the purpose is to switch partition when needed, we really do want to one real device. So I propose a new solution as: Assume there is two sd/mmc controller on the board, named as mmc0mmc1. The mmc0 attach with a sd card, and mmc1 attach with a emmc that has partition supported. Then we would have mmc(2, 3, 4, 5, 6, 7, 8) faked device map to mmc0 , mmc(9, 10, 11, 12, 13, 14, 15) map to mmc1. Give the command as mmc read 9 0x100 0 0x10, uboot would get the real device num by 9/7, while hardware part num is (9-1-7*real_dev_num) that is 1. So we need to make mmc1 send the switch part 1 command to the emmc, then perform the read operation. If we want to run mmc read 5 0x1 0x10 0x5, the sd attach on mmc0 has no hardware partition suppport, it would simply refuse to execute that command. Or if we want to be more gracefully handled, we could let the read 5 perform like the read 0 command. Best regards, Lei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Is it possible to load the uboot.bin file to RAM area instead FLASH?
Dear All, I want to load the uboot.bin on to my target board through JTAG into the SDRAM area? Is it possible to load the uboot.bin file into the RAM are instead of FLASH area? Sorry, If I asked a silly question. I am new bie. Regards, Madhavi ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/5] USB RNDIS gadget support
The patch series integrates RNDIS protocol support into the current U-Boot USB gadget stack to talk with Windows host. Synced with linux-2.6.26 version (latest one that has simple, non-composite gadget architecture), therefore I've kept checkpatch warnings about typedefs and 80 character lines, but I'm glad to discuss necessity and ways to fix them. Actually this protocol should not require to make any changes in existing USB device controller drivers. And sorry for the huge RNDIS patch. Vitaly Kuzmichev (5): USB-CDC: handle interrupts after dropped pullup USB-CDC: Port struct net_device_stats USB-CDC: Move struct declaration before its use USB: Add USB RNDIS gadget protocol USB-RNDIS: Send RNDIS state on disconnecting drivers/usb/gadget/Makefile |1 + drivers/usb/gadget/ether.c | 777 ++--- drivers/usb/gadget/ndis.h | 217 +++ drivers/usb/gadget/rndis.c | 1317 +++ drivers/usb/gadget/rndis.h | 260 + include/linux/netdevice.h | 65 +++ include/linux/usb/cdc.h |6 +- 7 files changed, 2550 insertions(+), 93 deletions(-) create mode 100644 drivers/usb/gadget/ndis.h create mode 100644 drivers/usb/gadget/rndis.c create mode 100644 drivers/usb/gadget/rndis.h create mode 100644 include/linux/netdevice.h -- 1.7.3.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/5] USB-CDC: handle interrupt after dropped pullup
Disconnecting USB gadget with pending interrupt may cause its wrong
handling in the next time when interface will be started again
(especially actual for RNDIS). This interrupt may force the gadget
to queue unexpected response before setup stage.
Despite the fact that such interrupt handled after dropped pullup
also may add pending response, this will not bring to any issues due to
usb_ep_disable (which clears the queue) called on gadget unregistering.
Signed-off-by: Vitaly Kuzmichev vkuzmic...@mvista.com
---
drivers/usb/gadget/ether.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/gadget/ether.c b/drivers/usb/gadget/ether.c
index 01deeb1..079acea 100644
--- a/drivers/usb/gadget/ether.c
+++ b/drivers/usb/gadget/ether.c
@@ -1926,6 +1926,13 @@ void usb_eth_halt(struct eth_device *netdev)
return;
usb_gadget_disconnect(dev-gadget);
+
+ /* Clear pending interrupt */
+ if (dev-network_started) {
+ usb_gadget_handle_interrupts();
+ dev-network_started = 0;
+ }
+
usb_gadget_unregister_driver(eth_driver);
}
--
1.7.3.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/5] USB-CDC: Port struct net_device_stats
Port struct net_device_stats and statistics collecting needed for
RNDIS protocol.
Signed-off-by: Vitaly Kuzmichev vkuzmic...@mvista.com
---
drivers/usb/gadget/ether.c | 41 +++
include/linux/netdevice.h | 65
2 files changed, 106 insertions(+), 0 deletions(-)
create mode 100644 include/linux/netdevice.h
diff --git a/drivers/usb/gadget/ether.c b/drivers/usb/gadget/ether.c
index 079acea..8aa6240 100644
--- a/drivers/usb/gadget/ether.c
+++ b/drivers/usb/gadget/ether.c
@@ -22,6 +22,7 @@
#include common.h
#include asm/errno.h
+#include linux/netdevice.h
#include linux/usb/ch9.h
#include linux/usb/cdc.h
#include linux/usb/gadget.h
@@ -175,6 +176,7 @@ struct eth_dev {
struct usb_request *tx_req, *rx_req;
struct eth_device *net;
+ struct net_device_stats stats;
unsigned inttx_qlen;
unsignedzlp:1;
@@ -1271,7 +1273,31 @@ static int rx_submit(struct eth_dev *dev, struct
usb_request *req,
static void rx_complete(struct usb_ep *ep, struct usb_request *req)
{
+ struct eth_dev *dev = ep-driver_data;
+
debug(%s: status %d\n, __func__, req-status);
+ switch (req-status) {
+ /* normal completion */
+ case 0:
+ dev-stats.rx_packets++;
+ dev-stats.rx_bytes += req-length;
+ break;
+
+ /* software-driven interface shutdown */
+ case -ECONNRESET: /* unlink */
+ case -ESHUTDOWN:/* disconnect etc */
+ /* for hardware automagic (such as pxa) */
+ case -ECONNABORTED: /* endpoint reset */
+ break;
+
+ /* data overrun */
+ case -EOVERFLOW:
+ dev-stats.rx_over_errors++;
+ /* FALLTHROUGH */
+ default:
+ dev-stats.rx_errors++;
+ break;
+ }
packet_received = 1;
}
@@ -1300,7 +1326,22 @@ fail1:
static void tx_complete(struct usb_ep *ep, struct usb_request *req)
{
+ struct eth_dev *dev = ep-driver_data;
+
debug(%s: status %s\n, __func__, (req-status) ? failed : ok);
+ switch (req-status) {
+ default:
+ dev-stats.tx_errors++;
+ debug(tx err %d\n, req-status);
+ /* FALLTHROUGH */
+ case -ECONNRESET: /* unlink */
+ case -ESHUTDOWN:/* disconnect etc */
+ break;
+ case 0:
+ dev-stats.tx_bytes += req-length;
+ }
+ dev-stats.tx_packets++;
+
packet_sent = 1;
}
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
new file mode 100644
index 000..870d8b4
--- /dev/null
+++ b/include/linux/netdevice.h
@@ -0,0 +1,65 @@
+/*
+ * INETAn implementation of the TCP/IP protocol suite for the
LINUX
+ * operating system. INET is implemented using the BSD Socket
+ * interface as the means of communication with the user level.
+ *
+ * Definitions for the Interfaces handler.
+ *
+ * Version:@(#)dev.h 1.0.10 08/12/93
+ *
+ * Authors:Ross Biro
+ * Fred N. van Kempen, wal...@uwalt.nl.mugnet.org
+ * Corey Minyard wf-rch!miny...@relay.eu.net
+ * Donald J. Becker, bec...@cesdis.gsfc.nasa.gov
+ * Alan Cox, alan@linux.org
+ * Bjorn Ekwall. bj...@blox.se
+ * Pekka Riikonen priik...@poseidon.pspt.fi
+ *
+ * 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.
+ *
+ * Moved to /usr/include/linux for NET3
+ */
+#ifndef _LINUX_NETDEVICE_H
+#define _LINUX_NETDEVICE_H
+
+/*
+ * Network device statistics. Akin to the 2.0 ether stats but
+ * with byte counters.
+ */
+
+struct net_device_stats {
+ unsigned long rx_packets; /* total packets received
*/
+ unsigned long tx_packets; /* total packets transmitted
*/
+ unsigned long rx_bytes; /* total bytes received
*/
+ unsigned long tx_bytes; /* total bytes transmitted
*/
+ unsigned long rx_errors; /* bad packets received
*/
+ unsigned long tx_errors; /* packet transmit problems
*/
+ unsigned long rx_dropped; /* no space in linux buffers
*/
+ unsigned long tx_dropped; /* no space available in linux
*/
+ unsigned long multicast; /* multicast packets received
*/
+ unsigned long collisions;
+
+ /* detailed rx_errors: */
+ unsigned long rx_length_errors;
+ unsigned long
[U-Boot] [PATCH 3/5] USB-CDC: Move struct declaration before its use
Signed-off-by: Vitaly Kuzmichev vkuzmic...@mvista.com
---
drivers/usb/gadget/ether.c | 70 ++-
1 files changed, 36 insertions(+), 34 deletions(-)
diff --git a/drivers/usb/gadget/ether.c b/drivers/usb/gadget/ether.c
index 8aa6240..c070f63 100644
--- a/drivers/usb/gadget/ether.c
+++ b/drivers/usb/gadget/ether.c
@@ -104,6 +104,42 @@ static const char driver_desc[] = DRIVER_DESC;
#define USB_CONNECT_TIMEOUT (3 * CONFIG_SYS_HZ)
/*-*/
+
+struct eth_dev {
+ struct usb_gadget *gadget;
+ struct usb_request *req; /* for control responses */
+ struct usb_request *stat_req; /* for cdc status */
+
+ u8 config;
+ struct usb_ep *in_ep, *out_ep, *status_ep;
+ const struct usb_endpoint_descriptor
+ *in, *out, *status;
+
+ struct usb_request *tx_req, *rx_req;
+
+ struct eth_device *net;
+ struct net_device_stats stats;
+ unsigned inttx_qlen;
+
+ unsignedzlp:1;
+ unsignedcdc:1;
+ unsignedsuspended:1;
+ unsignednetwork_started:1;
+ u16 cdc_filter;
+ unsigned long todo;
+ int mtu;
+#defineWORK_RX_MEMORY 0
+ u8 host_mac[ETH_ALEN];
+};
+
+/*
+ * This version autoconfigures as much as possible at run-time.
+ *
+ * It also ASSUMES a self-powered device, without remote wakeup,
+ * although remote wakeup support would make sense.
+ */
+
+/*-*/
static struct eth_dev l_ethdev;
static struct eth_device l_netdev;
static struct usb_gadget_driver eth_driver;
@@ -163,40 +199,6 @@ static inline int BITRATE(struct usb_gadget *g)
}
#endif
-struct eth_dev {
- struct usb_gadget *gadget;
- struct usb_request *req; /* for control responses */
- struct usb_request *stat_req; /* for cdc status */
-
- u8 config;
- struct usb_ep *in_ep, *out_ep, *status_ep;
- const struct usb_endpoint_descriptor
- *in, *out, *status;
-
- struct usb_request *tx_req, *rx_req;
-
- struct eth_device *net;
- struct net_device_stats stats;
- unsigned inttx_qlen;
-
- unsignedzlp:1;
- unsignedcdc:1;
- unsignedsuspended:1;
- unsignednetwork_started:1;
- u16 cdc_filter;
- unsigned long todo;
- int mtu;
-#defineWORK_RX_MEMORY 0
- u8 host_mac[ETH_ALEN];
-};
-
-/*
- * This version autoconfigures as much as possible at run-time.
- *
- * It also ASSUMES a self-powered device, without remote wakeup,
- * although remote wakeup support would make sense.
- */
-
/*-*/
/*
--
1.7.3.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/5] USB-RNDIS: Send RNDIS state on disconnecting
Add waiting for receiving Ethernet gadget state on the Windows host
side before dropping pullup, but keep it for debug.
Signed-off-by: Vitaly Kuzmichev vkuzmic...@mvista.com
---
drivers/usb/gadget/ether.c | 23 +++
drivers/usb/gadget/rndis.c |5 +
drivers/usb/gadget/rndis.h |8
3 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/gadget/ether.c b/drivers/usb/gadget/ether.c
index f909267..9fb0e80 100644
--- a/drivers/usb/gadget/ether.c
+++ b/drivers/usb/gadget/ether.c
@@ -1921,10 +1921,22 @@ static void eth_start(struct eth_dev *dev, gfp_t
gfp_flags)
static int eth_stop(struct eth_dev *dev)
{
+#ifdef RNDIS_COMPLETE_SIGNAL_DISCONNECT
+ unsigned long ts;
+ unsigned long timeout = CONFIG_SYS_HZ; /* 1 sec to stop RNDIS */
+#endif
+
if (rndis_active(dev)) {
rndis_set_param_medium(dev-rndis_config, NDIS_MEDIUM_802_3, 0);
rndis_signal_disconnect(dev-rndis_config);
+#ifdef RNDIS_COMPLETE_SIGNAL_DISCONNECT
+ /* Wait until host receives OID_GEN_MEDIA_CONNECT_STATUS */
+ ts = get_timer(0);
+ while (get_timer(ts) timeout)
+ usb_gadget_handle_interrupts();
+#endif
+
rndis_uninit(dev-rndis_config);
dev-rndis = 0;
}
@@ -2486,6 +2498,17 @@ void usb_eth_halt(struct eth_device *netdev)
if (!dev-gadget)
return;
+ /*
+* Some USB controllers may need additional deinitialization here
+* before dropping pull-up (also due to hardware issues).
+* For example: unhandled interrupt with status stage started may
+* bring the controller to fully broken state (until board reset).
+* There are some variants to debug and fix such cases:
+* 1) In the case of RNDIS connection eth_stop can perform additional
+* interrupt handling. See RNDIS_COMPLETE_SIGNAL_DISCONNECT definition.
+* 2) 'pullup' callback in your UDC driver can be improved to perform
+* this deinitialization.
+*/
eth_stop(dev);
usb_gadget_disconnect(dev-gadget);
diff --git a/drivers/usb/gadget/rndis.c b/drivers/usb/gadget/rndis.c
index 3e3f740..886c093 100644
--- a/drivers/usb/gadget/rndis.c
+++ b/drivers/usb/gadget/rndis.c
@@ -995,7 +995,12 @@ int rndis_signal_disconnect(int configNr)
rndis_per_dev_params[configNr].media_state
= NDIS_MEDIA_STATE_DISCONNECTED;
+#ifdef RNDIS_COMPLETE_SIGNAL_DISCONNECT
+ return rndis_indicate_status_msg(configNr,
+ RNDIS_STATUS_MEDIA_DISCONNECT);
+#else
return 0;
+#endif
}
void rndis_uninit(int configNr)
diff --git a/drivers/usb/gadget/rndis.h b/drivers/usb/gadget/rndis.h
index 73a1204..d9e3a75 100644
--- a/drivers/usb/gadget/rndis.h
+++ b/drivers/usb/gadget/rndis.h
@@ -17,6 +17,14 @@
#include ndis.h
+/*
+ * By default rndis_signal_disconnect does not send status message about
+ * RNDIS disconnection to USB host (indicated as cable disconnected).
+ * Define RNDIS_COMPLETE_SIGNAL_DISCONNECT to send it.
+ * However, this will cause 1 sec delay on Ethernet device halt.
+ * Usually you do not need to define it. Mostly usable for debugging.
+ */
+
#define RNDIS_MAXIMUM_FRAME_SIZE 1518
#define RNDIS_MAX_TOTAL_SIZE 1558
--
1.7.3.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Is it possible to load the uboot.bin file to RAM area instead FLASH?
On Fri, Feb 11, 2011 at 11:19 PM, Madhavi Manchala madhavi.li...@gmail.com wrote: Dear All, I want to load the uboot.bin on to my target board through JTAG into the SDRAM area? Is it possible to load the uboot.bin file into the RAM are instead of FLASH area? Sorry, If I asked a silly question. I am new bie. are instead of FLASH area? Certainly, it can. But you should make sure your jtag already init the dram and then load your uboot exactly at the CONFIG_SYS_TEXT_BASE. If your sdram is large enough, or the uboot code is small enough, you don't need the dram init. But begin at the TEXT_BASE still is a must. Best regards, Lei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] merge conflicts during git pull
Wolfgang, just wanted to update my local U-Boot master branch an got some errors I don't understand (since I'm still a git newbie). This is what I have: git originally cloned from public repo - thus I have in .git/config : [remote origin] fetch = +refs/heads/*:refs/remotes/origin/* url = git://www.denx.de/git/u-boot.git The master branch gets *never* touched. All my work is done in board specific branches. git branch -a gives : M7 MergerBox * master remotes/origin/HEAD - origin/master remotes/origin/GPL-Cleanup remotes/origin/i.MX31 remotes/origin/lwmon5 remotes/origin/master remotes/origin/next remotes/origin/tx25 remotes/origin/u-boot-2009.11.y Currently the repo is clean, i.e. everything committed and I did a git co master and git pull. I get a lot of conflicts on files I definitely never touched : # Unmerged paths: # (use git add/rm file... as appropriate to mark resolution) # #both modified: arch/arm/config.mk #both modified: arch/arm/cpu/arm1136/mx35/Makefile #both modified: arch/arm/cpu/arm1176/start.S #both modified: arch/arm/cpu/arm720t/start.S #both modified: arch/arm/cpu/arm920t/start.S #both modified: arch/arm/cpu/arm925t/start.S #added by them: arch/arm/cpu/arm926ejs/armada100/Makefile #both modified: arch/arm/cpu/arm946es/start.S #both modified: arch/arm/cpu/arm_intcm/start.S #both modified: arch/arm/cpu/armv7/omap3/emif4.c #both modified: arch/arm/cpu/ixp/start.S #both modified: arch/arm/cpu/lh7a40x/start.S #both modified: arch/arm/cpu/s3c44b0/start.S #both modified: arch/arm/cpu/sa1100/start.S #both modified: arch/arm/include/asm/arch-mx25/imx-regs.h #both modified: arch/arm/include/asm/arch-mx5/imx-regs.h #both modified: arch/powerpc/config.mk #both added: arch/powerpc/cpu/74xx_7xx/u-boot.lds #both modified: arch/powerpc/cpu/mpc512x/u-boot.lds #both modified: arch/powerpc/cpu/mpc5xx/u-boot.lds #both modified: arch/powerpc/cpu/mpc5xxx/u-boot.lds #both modified: arch/powerpc/cpu/mpc8220/u-boot.lds #both modified: arch/powerpc/cpu/mpc824x/u-boot.lds #both modified: arch/powerpc/cpu/mpc8260/u-boot.lds #both modified: arch/powerpc/cpu/mpc83xx/u-boot.lds #both modified: arch/powerpc/cpu/ppc4xx/u-boot.lds #both modified: arch/powerpc/include/asm/config.h #deleted by them:board/atum8548/atum8548.c #added by them: board/cm_t35/Makefile #added by us:board/dave/PPChameleonEVB/u-boot.lds #both modified: board/davinci/common/misc.c #both modified: board/emk/top9000/Makefile #both modified: board/freescale/corenet_ds/pci.c #both deleted: board/freescale/mpc7448hpc2/u-boot.lds #both modified: board/freescale/mpc8536ds/mpc8536ds.c #both modified: board/freescale/mpc8544ds/mpc8544ds.c #both modified: board/freescale/mpc8548cds/mpc8548cds.c . Have I missed anything ? Is there a way to get automagically merged whatever there might be to merge ? Any help is welcome. -- Regards, Andre MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Is it possible to load the uboot.bin file to RAM area instead FLASH?
Dear Lei Wen, In message aanlktin7zsxvqjkp1htovf44mtfknsjr2df9bsbkt...@mail.gmail.com you wrote: If your sdram is large enough, or the uboot code is small enough, you don't need the dram init. But begin at the TEXT_BASE still is a must. Hugh? You _always_ must make sure the RAM has been initialized first. 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 Perl itself is usually pretty good about telling you what you shouldn't do. :-) - Larry Wall in 11...@jpl-devvax.jpl.nasa.gov ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] unzip: return uncompressed size in `filesize', and print it.
Hi Wolfgang, - return !!gunzip((void *) dst, dst_len, (void *) src, src_len); + rc = gunzip((void *) dst, dst_len, (void *) src, src_len); + + printf(Uncompressed size: %ld = 0x%lX\n, src_len, src_len); + sprintf(buf, %lX, src_len); + setenv(filesize, buf); + + return !!rc; What about: if (rc) return rc; printf(Uncompressed size: %ld = 0x%lX\n, src_len, src_len); sprintf(buf, %lX, src_len); setenv(filesize, buf); return 0; This will prevent printing and setting of bogus values when an invalid or overly large image is unzipped. Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH ATMEL REWORK] update arm/at91rm9200 work with rework rework110202
Dear Andreas Bießmann, I'm offline for the net 10 days. So I fast include your comments to a V2 patch version Am 11.02.2011 09:11, schrieb Andreas Bießmann: Dear Jens Scharsig, Am 10.02.2011 um 20:31 schrieb Jens Scharsig: * update arm920t/at91 to ATMEL_xxx name scheme * convert at91rm9200ek and eb_cpux9k2 board to ATMEL_xxx name scheme * update arm920t/at91 soc lib * update at91_emac driver Signed-off-by: Jens Scharsig js_at...@scharsoft.de Tested-by: Andreas Bießmann andreas.de...@gmail.com But some changes I have prepare a second version of my patch. --- The eb_cpux9k2 board can compile and runs after patch changes The at91rm9200ek can compile, but i have no hardware to test it. at91rm9200ek is working but the change for timer.c is needed The timer.c changes I sent i a previous patch. I have join them to V2 Testet peripheral for at91rm9200ek is: - USB (fatls) - EMAC (tftp) +#define CONFIG_AT91FAMILY /* it's a member of AT91 */ +#define CONFIG_ARM920T /* This is an ARM920T Core */ + These are defined in board header .. I saw they are defined also in other at91xxx.h files, we should discuss where to define these since all of the at91xx.h files are included by hardware.h In V2 a have remove the define from board config's /* Periperial Identifiers */ [snip changes to at91rm9200.h which are obviously OK] +#define ATMEL_PIO_PORTS 4 /* theese SoCs have 3 PIO */ 3 or 4 PIO? 3 for PLCC and 4 for BGA variants. In PLCC the 4th port is not bound out. I set the comment to 4 in V2 + please remove this additional empty line removed #define CONFIG_DRIVER_AT91EMAC 1 #define CONFIG_DRIVER_AT91EMAC_QUIET 1 +/* +#define CONFIG_DRIVER_MACB 1 +*/ why this? Either it is needed or not. waste from testing, removed Best regard Jens Scharsig ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH ATMEL REWORK][V2] update arm/at91rm9200 work with rework rework110202
* convert at91rm9200ek and eb_cpux9k2 board to ATMEL_xxx name scheme
* Fix: timer.c compile error io.h not found with arm/at91rm9200
* update arm920t/at91 to ATMEL_xxx name scheme
* update arm920t/at91 soc lib
* update at91_emac driver
Signed-off-by: Jens Scharsig js_at...@scharsoft.de
---
arch/arm/cpu/arm920t/at91/reset.c |2 +-
arch/arm/cpu/arm920t/at91/timer.c | 12 +-
arch/arm/include/asm/arch-at91/at91_mc.h| 12 +-
arch/arm/include/asm/arch-at91/at91_pmc.h | 10 +-
arch/arm/include/asm/arch-at91/at91rm9200.h | 209 ++-
board/BuS/eb_cpux9k2/cpux9k2.c | 52
board/atmel/at91rm9200ek/at91rm9200ek.c |4 +-
board/atmel/at91rm9200ek/led.c | 22 ++--
drivers/net/at91_emac.c | 32 ++--
include/configs/at91rm9200ek.h |5 +-
include/configs/eb_cpux9k2.h| 23 ++--
11 files changed, 196 insertions(+), 187 deletions(-)
diff --git a/arch/arm/cpu/arm920t/at91/reset.c
b/arch/arm/cpu/arm920t/at91/reset.c
index 51043ec..4fa0f98 100644
--- a/arch/arm/cpu/arm920t/at91/reset.c
+++ b/arch/arm/cpu/arm920t/at91/reset.c
@@ -42,7 +42,7 @@ void __attribute__((weak)) board_reset(void)
void reset_cpu(ulong ignored)
{
- at91_st_t *st = (at91_st_t *) AT91_ST_BASE;
+ at91_st_t *st = (at91_st_t *) ATMEL_BASE_ST;
#if defined(CONFIG_AT91RM9200_USART)
/*shutdown the console to avoid strange chars during reset */
serial_exit();
diff --git a/arch/arm/cpu/arm920t/at91/timer.c
b/arch/arm/cpu/arm920t/at91/timer.c
index d9a024f..f0ad7d6 100644
--- a/arch/arm/cpu/arm920t/at91/timer.c
+++ b/arch/arm/cpu/arm920t/at91/timer.c
@@ -32,7 +32,7 @@
#include common.h
-#include asm/arch/io.h
+#include asm/io.h
#include asm/arch/hardware.h
#include asm/arch/at91_tc.h
#include asm/arch/at91_pmc.h
@@ -44,11 +44,11 @@ DECLARE_GLOBAL_DATA_PTR;
int timer_init(void)
{
- at91_tc_t *tc = (at91_tc_t *) AT91_TC_BASE;
- at91_pmc_t *pmc = (at91_pmc_t *) AT91_PMC_BASE;
+ at91_tc_t *tc = (at91_tc_t *) ATMEL_BASE_TC;
+ at91_pmc_t *pmc = (at91_pmc_t *) ATMEL_BASE_PMC;
/* enables TC1.0 clock */
- writel(1 AT91_ID_TC0, pmc-pcer); /* enable clock */
+ writel(1 ATMEL_ID_TC0, pmc-pcer); /* enable clock */
writel(0, tc-bcr);
writel(AT91_TC_BMR_TC0XC0S_NONE | AT91_TC_BMR_TC1XC1S_NONE |
@@ -96,14 +96,14 @@ void __udelay(unsigned long usec)
void reset_timer_masked(void)
{
/* reset time */
- at91_tc_t *tc = (at91_tc_t *) AT91_TC_BASE;
+ at91_tc_t *tc = (at91_tc_t *) ATMEL_BASE_TC;
gd-lastinc = readl(tc-tc[0].cv) 0x;
gd-tbl = 0;
}
ulong get_timer_raw(void)
{
- at91_tc_t *tc = (at91_tc_t *) AT91_TC_BASE;
+ at91_tc_t *tc = (at91_tc_t *) ATMEL_BASE_TC;
u32 now;
now = readl(tc-tc[0].cv) 0x;
diff --git a/arch/arm/include/asm/arch-at91/at91_mc.h
b/arch/arm/include/asm/arch-at91/at91_mc.h
index acfbd10..e0d1320 100644
--- a/arch/arm/include/asm/arch-at91/at91_mc.h
+++ b/arch/arm/include/asm/arch-at91/at91_mc.h
@@ -23,12 +23,12 @@
#ifndef AT91_MC_H
#define AT91_MC_H
-#define AT91_ASM_MC_EBI_CSA(AT91_MC_BASE + 0x60)
-#define AT91_ASM_MC_EBI_CFG(AT91_MC_BASE + 0x64)
-#define AT91_ASM_MC_SMC_CSR0 (AT91_MC_BASE + 0x70)
-#define AT91_ASM_MC_SDRAMC_MR (AT91_MC_BASE + 0x90)
-#define AT91_ASM_MC_SDRAMC_TR (AT91_MC_BASE + 0x94)
-#define AT91_ASM_MC_SDRAMC_CR (AT91_MC_BASE + 0x98)
+#define AT91_ASM_MC_EBI_CSA(ATMEL_BASE_MC + 0x60)
+#define AT91_ASM_MC_EBI_CFG(ATMEL_BASE_MC + 0x64)
+#define AT91_ASM_MC_SMC_CSR0 (ATMEL_BASE_MC + 0x70)
+#define AT91_ASM_MC_SDRAMC_MR (ATMEL_BASE_MC + 0x90)
+#define AT91_ASM_MC_SDRAMC_TR (ATMEL_BASE_MC + 0x94)
+#define AT91_ASM_MC_SDRAMC_CR (ATMEL_BASE_MC + 0x98)
#ifndef __ASSEMBLY__
diff --git a/arch/arm/include/asm/arch-at91/at91_pmc.h
b/arch/arm/include/asm/arch-at91/at91_pmc.h
index fb8bb17..086cb9b 100644
--- a/arch/arm/include/asm/arch-at91/at91_pmc.h
+++ b/arch/arm/include/asm/arch-at91/at91_pmc.h
@@ -17,11 +17,11 @@
#ifndef AT91_PMC_H
#define AT91_PMC_H
-#defineAT91_ASM_PMC_MOR(AT91_PMC_BASE + 0x20)
-#defineAT91_ASM_PMC_PLLAR (AT91_PMC_BASE + 0x28)
-#defineAT91_ASM_PMC_PLLBR (AT91_PMC_BASE + 0x2c)
-#define AT91_ASM_PMC_MCKR (AT91_PMC_BASE + 0x30)
-#define AT91_ASM_PMC_SR(AT91_PMC_BASE + 0x68)
+#defineAT91_ASM_PMC_MOR(ATMEL_BASE_PMC + 0x20)
+#defineAT91_ASM_PMC_PLLAR (ATMEL_BASE_PMC + 0x28)
+#defineAT91_ASM_PMC_PLLBR (ATMEL_BASE_PMC + 0x2c)
+#define AT91_ASM_PMC_MCKR (ATMEL_BASE_PMC + 0x30)
+#define AT91_ASM_PMC_SR(ATMEL_BASE_PMC + 0x68)
#ifndef __ASSEMBLY__
diff --git a/arch/arm/include/asm/arch-at91/at91rm9200.h
b/arch/arm/include/asm/arch-at91/at91rm9200.h
index 1bee6f2..19ad7f4 100644
---
Re: [U-Boot] {Spam?} u-boot-usb DFU working but need some ideas
Hi Wolfgang, In message 201102102015.59437.korg...@home.nl you wrote: The GPBR is optional in my code. I just use it because it's the nicest solution for me over the following options : I haven't seen your code yet, so I may misunderstand what you are actually referring to, but from what it sounds I think that should not be optional, but strictly separate from the DFU code. It is separate or I will make sure it is when I post it. Do you mean separate patches to add for example the sam9g45 USB controller and another patch to add DFU and another one to add my board ? Yes. OK. It does make sense to that, I just wonder how to generate those patches.. I know which files I want to include in separate patches, but how do I do that ? Normally you do this when developing the code. Than I just check out a new u-boot-usb and port my code in there in order of the patches. It sounds not very difficult and at least makes sure I have several patches created the way it should. If you already have alltogehter as a huge pile of a mess, then you will have to go thtrough splitting this up. Either completely manually (ouch...) or by using git's interactive capabilities - for example, git add --interactive can be used to select even single lines from hunks of changes into the next commit. Yes, this is a painful work, but it needs to be done to make your code acceptable for mainline. Understood. I will go for the manual way as I didn't do much changes to the existing u- boot code anyway. It's a fairly clean implementation so I should be finished with in a couple of hours I think. I'll post the items this weekend. Thanks for all the help so far, Marcel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] arm1136: Fix NAND boot
Hi I've tested Fabio's patch series and it makes the i.MX31 PDK boot nicely from NAND again. So from my point of view I recommend to use these patches. Best regards, Magnus On 02/09/2011 12:17 PM, Fabio Estevam wrote: Signed-off-by: Fabio Estevam fabio.este...@freescale.com Signed-off-by: Magnus Lilja lilja.mag...@gmail.com --- arch/arm/cpu/arm1136/start.S | 16 1 files changed, 4 insertions(+), 12 deletions(-) diff --git a/arch/arm/cpu/arm1136/start.S b/arch/arm/cpu/arm1136/start.S index b771d31..bab2868 100644 --- a/arch/arm/cpu/arm1136/start.S +++ b/arch/arm/cpu/arm1136/start.S @@ -163,15 +163,7 @@ call_board_init_f: bic sp, sp, #7 /* 8-byte alignment for ABI compliance */ ldr r0,=0x -#ifdef CONFIG_NAND_SPL - bl nand_boot -#else -#ifdef CONFIG_ONENAND_IPL - bl start_oneboot -#else bl board_init_f -#endif /* CONFIG_ONENAND_IPL */ -#endif /* CONFIG_NAND_SPL */ /*--*/ @@ -267,10 +259,10 @@ clbss_l:str r2, [r0]/* clear loop...*/ */ #ifdef CONFIG_NAND_SPL ldr r0, _nand_boot_ofs - adr r1, _start - add pc, r0, r1 -_nand_boot_ofs - : .word nand_boot - _start + mov pc, r0 + +_nand_boot_ofs: + .word nand_boot #else jump_2_ram: ldr r0, _board_init_r_ofs ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Altering cpu/mpc85xx/start.S to set GPIO
On Wed, 9 Feb 2011 23:20:03 -0800 Rick Ramstetter rick.ramstet...@gmail.com wrote: As per the P2020 QoriQ manual's section 4.5.3 (p. 4-48, QorIQ P2020 Integrated Processor Reference Manual), I ought to be able to access CCSRBAR without mapping it through a TLB; 4.5.3 says you don't need a LAW, it doesn't say anything about not needing a TLB entry. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] merge conflicts during git pull
Dear Andre, In message 4d555611.2040...@matrix-vision.de you wrote: just wanted to update my local U-Boot master branch an got some errors I don't understand (since I'm still a git newbie). ... Currently the repo is clean, i.e. everything committed and I did a git co master and git pull. I get a lot of conflicts on files I definitely never touched : ... Have I missed anything ? Is there a way to get automagically merged whatever there might be to merge ? Sorry, I have no idea what happenend of your system. I can see no issues on our side. Here is what the top of tree of the master branch should look like for you: == (HEAD, origin/master, origin/HEAD, custodians/master, custodians/HEAD, master) 494a7d2 2011-02-09 21:22:58 +0100 Merge branch 'master' of git://git.denx.de/u-boot-nand-flash 65b57eb 2011-02-09 20:54:53 +0100 Merge branch 'next' of git://git.denx.de/u-boot-nios fced09a 2011-02-09 20:50:26 +0100 Merge branch 'master' of git://git.denx.de/u-boot-ppc4xx eef1d71 2011-02-08 15:25:02 -0600 NAND: env: remember the flags used in the previous environment d8a593c 2011-02-08 08:29:53 -0500 nios2: add gpio_is_valid 85debef 2011-02-08 08:29:53 -0500 nios2: use long for ssize_t df8f125 2011-02-08 08:29:53 -0500 altera_spi: add spi_set_speed e91d545 2011-02-08 08:29:53 -0500 nios2: add gpio_free 2da0fc0 2011-02-07 11:13:16 +0100 ppc4xx: Add DLVision-10G board support 8d4addc 2011-02-06 22:41:53 +0100 Merge branch 'master' of git://git.denx.de/u-boot-mpc83xx 367c665 2011-02-06 22:39:50 +0100 Merge branch 'master' of git://git.denx.de/u-boot-usb e9e481f 2011-02-06 22:28:34 +0100 Merge branch 'master' of git://git.denx.de/u-boot-mpc85xx 26e5f79 2011-02-05 17:06:57 -0600 mpc83xx: Use correct register to calculate clocks. 10fa8d7 2011-02-05 17:01:52 -0600 mpc83xx: fix pcie configuration space read/write ce297a8 2011-02-05 13:54:51 +0100 USB: Change the necessary defines to get debug output cb44091 2011-02-05 13:54:51 +0100 USB: Fix device stati for removable and powerctrl (typo) f69b980 2011-02-04 21:44:46 +0100 Merge branch 'master' of git://git.denx.de/u-boot-nand-flash 04a641d 2011-02-04 14:04:21 -0600 powerpc/8xxx: Fix possible compile issue related to P1013 4bfa18f 2011-02-04 20:38:27 +0100 Merge branch 'master' of git://git.denx.de/u-boot-sh d34897d 2011-02-03 02:46:13 -0600 powerpc/85xx: Enable ECC on MPC8572DS 9167191 2011-02-03 02:46:13 -0600 powerpc/mpc85xx: implement workaround for errata DDR111 and DDR134 eb0aff7 2011-02-03 02:46:13 -0600 powerpc/85xx: Rename MPC8572 DDR erratum to DDR115 67f9447 2011-02-03 02:46:13 -0600 powerpc/85xx: Enable Errata command on MPC8572DS e1df0de 2011-02-03 02:46:12 -0600 powerpc/85xx: Remove unnecessary polling loop from DDR init 5103a03 2011-02-03 02:46:12 -0600 fsl_esdhc: Add the workaround for erratum ESDHC-A001 (enable on P2020) 6e7f0bc 2011-02-03 02:46:12 -0600 powerpc/85xx: Enable ESDHC111 Erratum on P2010/P2020 SoCs e72f467 2011-02-03 16:54:19 +0900 sh: sh7785lcr: Fix out of tree building 920a5dd 2011-02-02 16:14:08 -0600 NAND: Fix saving of redundand environment == (v2011.03-rc1) 42d44f6 2011-02-02 22:37:32 +0100 Prepare v2011.03-rc1 ... 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 For every complex problem, there is a solution that is simple, neat, and wrong. - Mark Twain ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] unzip: return uncompressed size in `filesize', and print it.
The unzip command did not provide a way for the caller to get any
information about the uncompressed size. To make it better usable in
scripts, we now store the uncompressed size in the `filesize'
variable, like we do when for example loading a file over the network
or when reading it from a file system. Following that analogy, it is
only consequent to also print the size.
Signed-off-by: Wolfgang Denk w...@denx.de
---
v2: return early in case of errors,
set 'filesize' only on success.
This also avoids the new 'rc' variable.
Courtesy to Peter Tyser for pointing out.
common/cmd_mem.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/common/cmd_mem.c b/common/cmd_mem.c
index ccf420a..4b524cf 100644
--- a/common/cmd_mem.c
+++ b/common/cmd_mem.c
@@ -1212,6 +1212,7 @@ int do_unzip ( cmd_tbl_t *cmdtp, int flag, int argc, char
* const argv[])
{
unsigned long src, dst;
unsigned long src_len = ~0UL, dst_len = ~0UL;
+ char buf[32];
switch (argc) {
case 4:
@@ -1225,7 +1226,14 @@ int do_unzip ( cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
return cmd_usage(cmdtp);
}
- return !!gunzip((void *) dst, dst_len, (void *) src, src_len);
+ if (gunzip((void *) dst, dst_len, (void *) src, src_len) != 0)
+ return 1;
+
+ printf(Uncompressed size: %ld = 0x%lX\n, src_len, src_len);
+ sprintf(buf, %lX, src_len);
+ setenv(filesize, buf);
+
+ return 0;
}
#endif /* CONFIG_CMD_UNZIP */
--
1.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] unzip: return uncompressed size in `filesize', and print it.
Dear Peter Tyser, In message 1297443439.965.1208.camel@petert you wrote: - return !!gunzip((void *) dst, dst_len, (void *) src, src_len); + rc = gunzip((void *) dst, dst_len, (void *) src, src_len); + + printf(Uncompressed size: %ld = 0x%lX\n, src_len, src_len); + sprintf(buf, %lX, src_len); + setenv(filesize, buf); + + return !!rc; What about: if (rc) return rc; printf(Uncompressed size: %ld = 0x%lX\n, src_len, src_len); sprintf(buf, %lX, src_len); setenv(filesize, buf); return 0; This will prevent printing and setting of bogus values when an invalid or overly large image is unzipped. Good point, will fix. 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 HANDLE WITH EXTREME CARE: This Product Contains Minute Electrically Charged Particles Moving at Velocities in Excess of Five Hundred Million Miles Per Hour. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH ATMEL REWORK][V2] update arm/at91rm9200 work with rework rework110202
Dear Jens Scharsig, In message 4d5573ca.9000...@scharsoft.de you wrote: * convert at91rm9200ek and eb_cpux9k2 board to ATMEL_xxx name scheme * Fix: timer.c compile error io.h not found with arm/at91rm9200 * update arm920t/at91 to ATMEL_xxx name scheme * update arm920t/at91 soc lib * update at91_emac driver ... /* Port B */ -#define AT91_PMX_BA_ERXCK0x0008 -#define AT91_PMX_BA_ECOL 0x0004 -#define AT91_PMX_BA_ERXDV0x0002 -#define AT91_PMX_BA_ERX3 0x0001 -#define AT91_PMX_BA_ERX2 0x8000 ^^^ Please, no space before tabs 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 Gewöhnlich glaubt der Mensch, wenn er nur Worte hört, es müsse sich dabei doch auch was denken lassen. -- Goethe, Faust I ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Altering cpu/mpc85xx/start.S to set GPIO
On Feb 11, 2011, at 12:55 PM, Scott Wood wrote: On Wed, 9 Feb 2011 23:20:03 -0800 Rick Ramstetter rick.ramstet...@gmail.com wrote: As per the P2020 QoriQ manual's section 4.5.3 (p. 4-48, QorIQ P2020 Integrated Processor Reference Manual), I ought to be able to access CCSRBAR without mapping it through a TLB; 4.5.3 says you don't need a LAW, it doesn't say anything about not needing a TLB entry. -Scott In think in the boot from SPI case there is a 4G TLB that maps 1:1 - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Fix to make U-Boot work with more USB sticks
Hi, 2011/2/7 Simon Glass s...@chromium.org: Hi Remy, I have now tested on OHCI with AT91SAM9G45 and found that the code already includes a longer timeout and does not have the submission bug. So for now I would like to replace that patch with a new one which I will send to the list today. OK For now I will drop the reset and restart parts of the patch since I don't have evidence that they are required. I still believe the reset is too ad-hoc, so am happy to resubmit that part of it if you like. Regarding your troubled sticks, can you please advise make / model numbers and USB ID? It would be good to at least look at these problems and see what can be done. I have for example these sticks that show problems on a OHCI host: 13fe:1a20 Kingston Technology Company Inc. 0204:6025 Chipsbank Microelectronics Co., Ltd CBM2080 Flash drive controller 2008:2018 Note that these sticks give only problems on a at91sam9261 processor if it runs on 200MHz (10MHz X-tal) and not if it runs on 198.656 MHz (18.432 MHz X-tal) One stick also stop showing the problem if it has been powered on for about 10 minutes...(Then it feels a little warmer). I have more sticks of the same brand/type/manufacturing-date that do not show a problem at all... Furthermore, the exact same software is being used in both cases, and same stick with same contents. U-boot since 2010.06 seems to be more sensitive to make these sticks fail, so there seems to be some regression here. Failure is usually being visualised as a stall of an endpoint. Sometimes failure of the stick is that hard, that a power cycle of the stick is required. I have not had the time to hook up the USB analyser to see what exactly is going wrong, but my guts tell me that there are some tricky timing issues involved. Kind regards, Remy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH ATMEL REWORK][V2] update arm/at91rm9200 work with rework rework110202
Dear Wolfgang Denk, Dear Jens Scharsig, In message4d5573ca.9000...@scharsoft.de you wrote: * convert at91rm9200ek and eb_cpux9k2 board to ATMEL_xxx name scheme * Fix: timer.c compile error io.h not found with arm/at91rm9200 * update arm920t/at91 to ATMEL_xxx name scheme * update arm920t/at91 soc lib * update at91_emac driver ... /* Port B */ -#define AT91_PMX_BA_ERXCK 0x0008 -#define AT91_PMX_BA_ECOL0x0004 -#define AT91_PMX_BA_ERXDV 0x0002 -#define AT91_PMX_BA_ERX30x0001 -#define AT91_PMX_BA_ERX20x8000 ^^^ Please, no space before tabs Those lines that are being removed by the patch. Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH ATMEL REWORK][V2] update arm/at91rm9200 work with rework rework110202
Dear Reinhard Meyer, In message 4d5597a8.9050...@emk-elektronik.de you wrote: Dear Wolfgang Denk, Dear Jens Scharsig, In message4d5573ca.9000...@scharsoft.de you wrote: * convert at91rm9200ek and eb_cpux9k2 board to ATMEL_xxx name scheme * Fix: timer.c compile error io.h not found with arm/at91rm9200 * update arm920t/at91 to ATMEL_xxx name scheme * update arm920t/at91 soc lib * update at91_emac driver ... /* Port B */ -#define AT91_PMX_BA_ERXCK 0x0008 -#define AT91_PMX_BA_ECOL 0x0004 -#define AT91_PMX_BA_ERXDV 0x0002 -#define AT91_PMX_BA_ERX3 0x0001 -#define AT91_PMX_BA_ERX2 0x8000 ^^^ Please, no space before tabs Those lines that are being removed by the patch. Oops. I marked the wrong line. I meant this one: - checkpatch ~/Mail/U-Boot/3377 WARNING: please, no space before tabs #379: FILE: arch/arm/include/asm/arch-at91/at91rm9200.h:112: +#define ATMEL_PMX_BA_ERX2 ^I0x8000$ 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 EMACS belongs in sys/errno.h: Editor too big! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Fix EHCI usb submit timeout and unify with OHCI
Hi, 2011/2/7 Simon Glass s...@chromium.org: Changed both to use a common timeout for URB submission, since they were using different values and EHCI's was too short. Also fixed EHCI to actually check if urb submission succeeded, rather than silently continuing into the weeds. Change-Id: I7f71499ffaa05187d8e5618db2419e1606007b82 Signed-off-by: Simon Glass s...@chromium.org --- drivers/usb/host/ehci-hcd.c | 10 +- drivers/usb/host/ohci-hcd.c | 7 +-- include/usb.h | 6 ++ 3 files changed, 16 insertions(+), 7 deletions(-) Applied to u-boot-usb Thanks. Remy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-video/master
Dear Anatolij Gustschin, In message 20110209215908.496be169@wker you wrote: Hallo Wolfgang, The following changes since commit 494a7d215bfba17f1a94736df40c332c8713c30e: Merge branch 'master' of git://git.denx.de/u-boot-nand-flash (2011-02-09 21:22:58 +0100) are available in the git repository at: git://git.denx.de/u-boot-video.git master Wolfgang Denk (1): cmd_bmp.c: message about compressed formats is debug info only. common/cmd_bmp.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 Not one hundred percent efficient, of course ... but nothing ever is. -- Kirk, Metamorphosis, stardate 3219.8 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [GIT PULL] Please pull u-boot-mpc85xx.git
Dear Kumar Gala, In message Pine.LNX.4.64.1102102344240.18114@localhost.localdomain you wrote: Some fixes for v2011.03: The following changes since commit 494a7d215bfba17f1a94736df40c332c8713c30e: Wolfgang Denk (1): Merge branch 'master' of git://git.denx.de/u-boot-nand-flash are available in the git repository at: git://git.denx.de/u-boot-mpc85xx master Kumar Gala (1): powerpc/85xx: Fix p1_p2_rdb boards.cfg Priyanka Jain (1): powerpc/85xx: corrected p1_p2_rdb EEPROM address Timur Tabi (1): fsl: update CRC after setting EEPROM identifier York Sun (1): powerpc/8xxx: Add additional cycle to write-to-read turnaound for DDR3 arch/powerpc/cpu/mpc8xxx/ddr/ctrl_regs.c |3 +++ arch/powerpc/cpu/mpc8xxx/ddr/ddr.h |2 +- board/freescale/common/sys_eeprom.c |1 + boards.cfg | 26 +- include/configs/P1_P2_RDB.h |3 +-- 5 files changed, 19 insertions(+), 16 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 morsel of genuine history is a thing so rare as to be always valuable. - Thomas Jefferson ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot usb-ethernet patch
Hi, 2011/2/10 Mehmet Fatih Özay mfatih.o...@ctech.com.tr: Hello all We are using OMAP 3530 board and SMSC9512 usb-ethernet adapter. The main goal is to connect this adapter through USB OTG port and initialize at u-boot. In order to do it, we are using your u-boot patches for usb-ethernet SMSC95xx ( we patch your patch file to our u-boot-release (version u-boot 2009.11-svn12). What we succeed so far is introducing SMSC9512 to the system.As you can see from debugging below, we couldnot succeed to configure SMSC9512 and so we couldnot make ethernet work. By the way, USB OTG is connected to the OMAP through TPS6593. You are using a rather old version of U-boot with a patchset that we cannot identify. Practically this means that you are on your own here. Please use a recent version of U-boot and try to re-reproduce the problem. Kind regards, Remy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 V2] Add USB host ethernet adapter support
Hi, 2011/2/8 Simon Glass s...@chromium.org: This adds support for using USB Ethernet dongles in host mode. This is just the framework - drivers will come later. A new config option called CONFIG_USB_HOST_ETHER can be defined in board config files to switch this on. The was originally written by NVIDIA and was cleaned up for release by the Chromium authors. Signed-off-by: Simon Glass s...@chromium.org --- Makefile | 1 + common/cmd_usb.c | 12 +++- common/usb.c | 6 ++- doc/README.usb | 4 +- drivers/usb/eth/Makefile | 45 ++ drivers/usb/eth/usb_ether.c | 143 +++ include/usb.h | 9 +++- include/usb_ether.h | 61 ++ net/eth.c | 47 +++ 9 files changed, 298 insertions(+), 30 deletions(-) create mode 100644 drivers/usb/eth/Makefile create mode 100644 drivers/usb/eth/usb_ether.c create mode 100644 include/usb_ether.h This patch does not seem to apply to u-boot-usb master branch... Can you please take a look at it? Kind regards, Remy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] at91 failures under temperature?
Hi, 2011/2/7 Joey Oravec jora...@drewtech.com: Hi - I've been investigating a problem involving the at91sam9261 processor. Across 2 or 3 years we've manufactured two products with: Crystal: 16.000 MHz Processor Clock: 240 MHz (PLLA *15) Master Clock: 120 MHz VDDCORE: 1.2v Based on testing history, about 10% of the assemblies fail starting above 30 degC. The simplest testcase to demonstrate is: 1) use uboot relocated to SDRAM as normal 2) enable caches 3) fill 16mb of SDRAM with a known pattern 4) use a test command to continually calculate and print CRC. As you apply heat to the processor the testcase will print an incorrect CRC. If the unit has not already crashed you can decrease the temperature and see the correct CRC again, which demonstrates that SDRAM hasn't flipped any bits. Extending ram timings or lowering master clock (ie. sdram bus clock) has no impact. Lowering the processor clock to 224 MHz makes the problem go away -- at this speed I can heat the processor to the rated 85 C and the testcase above will not fail. Also replacing the processor usually makes the problem go away. You won't see the problem with any variable changed: caches disabled, any processor clock below 240 MHz, or VDDCORE at 1.3v. I'm using PLL R/C calculated by the spreadsheet, and 240 MHz @ 1.2v should be within spec up to 85 C. I've requested failure analysis on some of the processors but I don't expect an answer any time soon. Is anybody else successful with a 240 MHz processor clock, or are you using a lower processor clock for greater reliability? Can you recommend any other diagnostics that might identify the root cause? In the meantime for maximum reliability, I recommend using a processor clock less than 240 MHz and checking your hardware with a similar testcase. Funny... I always thought the Master-CLK could not go above 100MHz... I do not know the exact reason any more... Either way, we use it for several years now at 200/100Mhz with a 10MHz crystal. Anyway: This problem is not related to U-boot in any way, and is therefor OT. You should discuss this with Atmel. And some good news: We had a similar problem last year. I will explain off-list. Kind regards, Remy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] BSS footprint of FAT very high - SPL issues
2011-02-01 09:26, Aneesh V skrev: Hi Vaibhav, On Tuesday 01 February 2011 12:22 PM, Bedia, Vaibhav wrote: Hi Aneesh, On Tuesday, February 01, 2011 10:54 AM, Aneesh V wrote: Dear Wolfgang, I had been working on creating an MMC SPL for OMAP4. OMAP boards typically support booting from the FAT partition of a removable SD/MMC card. So, we need to have FAT support in the SPL. But I am having some difficulties in adding FAT support to SPL. BSS footprint of fat.c is very high. It has three buffers each of size 64KB. To workaround this problem I have done something like below(The way x-loader works around this problem today). CONFIG_SYS_SPL_FAT_BUFFER_BASE is in SDRAM.Is this ok? [...] I guess you will hit a similar issue with the networking related code is used (I am not sure if SPL uses it). That also requires a decent size of bss. Luckily we don't need networking related code in SPL. I would prefer to have rest of the BSS in internal RAM itself. best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot The way this problem is fixed on the AT91 is to run at91bootstrap first. This program will initialize the SDRAM and copy u-boot to SDRAM. at91bootstrap fits into 4 kB of code, and a small amount of RAM, so it will run on real small CPUs. You could try to do the same, instead of spending a lot of time, trying to optimize. -- Best Regards Ulf Samuelsson ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mkimage: add -V option to print version information
Hi Wolfgang, Le 11/02/2011 09:56, Wolfgang Denk a écrit : Signed-off-by: Wolfgang Denkw...@denx.de --- tools/mkimage.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/tools/mkimage.c b/tools/mkimage.c index f5859d7..788484d 100644 --- a/tools/mkimage.c +++ b/tools/mkimage.c @@ -23,6 +23,7 @@ #include mkimage.h #includeimage.h +#includeversion.h static void copy_file(int, const char *, int); static void usage(void); @@ -246,6 +247,10 @@ main (int argc, char **argv) case 'v': params.vflag++; break; + case 'V': + printf(mkimage version %s\n, + U_BOOT_VERSION + 7); That 7 is a pretty awful magic number here, isn't it? At least if there's a sane reason for this it should be summarized in a short comment. + exit(EXIT_SUCCESS); case 'x': params.xflag++; break; @@ -590,6 +595,7 @@ usage () params.cmdname); fprintf (stderr,%s [-D dtc_options] -f fit-image.its fit-image\n, params.cmdname); + fprintf (stderr,%s -V == print version information and exit\n); exit (EXIT_FAILURE); } Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] mkimage: add -V option to print version information
Wolfgang, Please ignore my previous post on V1, I had not seen V2. My comment holds, though: Le 11/02/2011 13:22, Wolfgang Denk a écrit : Signed-off-by: Wolfgang Denkw...@denx.de --- v2: fix missing argument to printf() call. tools/mkimage.c |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/tools/mkimage.c b/tools/mkimage.c index f5859d7..127be57 100644 --- a/tools/mkimage.c +++ b/tools/mkimage.c @@ -23,6 +23,7 @@ #include mkimage.h #includeimage.h +#includeversion.h static void copy_file(int, const char *, int); static void usage(void); @@ -246,6 +247,10 @@ main (int argc, char **argv) case 'v': params.vflag++; break; + case 'V': + printf(mkimage version %s\n, + U_BOOT_VERSION + 7); If that magic number 7 (and the addition, as well) has any reason, it should at least be explained in a short comment. + exit(EXIT_SUCCESS); case 'x': params.xflag++; break; @@ -590,6 +595,8 @@ usage () params.cmdname); fprintf (stderr,%s [-D dtc_options] -f fit-image.its fit-image\n, params.cmdname); + fprintf (stderr,%s -V == print version information and exit\n, + params.cmdname); exit (EXIT_FAILURE); } Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] BSS footprint of FAT very high - SPL issues
Dear Ulf Samuelsson, In message 4d55a73c.6090...@atmel.com you wrote: The way this problem is fixed on the AT91 is to run at91bootstrap first. This program will initialize the SDRAM and copy u-boot to SDRAM. at91bootstrap fits into 4 kB of code, and a small amount of RAM, so it will run on real small CPUs. In mainline U-Boot we tend to use nand_spl instead. There should be no need for such externel, out-of-tree code. Thanks. 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 value of marriage is not that adults produce children, but that children produce adults.- Peter De Vries ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM: fix write*() I/O accessors
Commit 3c0659b ARM: Avoid compiler optimization for readb, writeb
and friends. introduced I/O accessors with memory barriers.
Unfortunately the new write*() accessors introduced a bug:
The problem is that the argument v gets evaluated twice. This
breaks code like used here (from drivers/net/dnet.c):
for (i = 0; i wrsz; i++)
writel(*bufp++, dnet-regs-TX_DATA_FIFO);
Use auxiliary variables to avoid such problems.
Signed-off-by: Wolfgang Denk w...@denx.de
Cc: Albert Aribaud albert.arib...@free.fr
Cc: Alexander Holler hol...@ahsoftware.de
Cc: Dirk Behme dirk.be...@googlemail.com
---
This patch fixes a pretty nasty problem. Everybody who has
experienced strange failures on ARM lately should apply it ASAP and
re-test. As far as I can tell at least the following drivers are
affected:
drivers/net/dnet.c: writel(*bufp++, dnet-regs-TX_DATA_FIFO);
drivers/usb/musb/musb_core.c: writeb(*data++, musbr-fifox[ep]);
drivers/mmc/pxa_mmc.c: writel(*src++, MMC_TXFIFO);
drivers/mmc/mxcmmc.c: writel(*buf++, host-base-buffer_access);
drivers/spi/davinci_spi.c: writel(data1_reg_val | *txp++, ds-regs-dat1);
Albert, please apply ASAP!
arch/arm/include/asm/io.h |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
index 3886f15..1fbc531 100644
--- a/arch/arm/include/asm/io.h
+++ b/arch/arm/include/asm/io.h
@@ -133,9 +133,9 @@ extern inline void __raw_readsl(unsigned int addr, void
*data, int longlen)
#define __iormb() dmb()
#define __iowmb() dmb()
-#define writeb(v,c)({ __iowmb(); __arch_putb(v,c); v; })
-#define writew(v,c)({ __iowmb(); __arch_putw(v,c); v; })
-#define writel(v,c)({ __iowmb(); __arch_putl(v,c); v; })
+#define writeb(v,c)({ u8 __v = v; __iowmb(); __arch_putb(__v,c); __v; })
+#define writew(v,c)({ u16 __v = v; __iowmb(); __arch_putw(__v,c); __v; })
+#define writel(v,c)({ u32 __v = v; __iowmb(); __arch_putl(__v,c); __v; })
#define readb(c) ({ u8 __v = __arch_getb(c); __iormb(); __v; })
#define readw(c) ({ u16 __v = __arch_getw(c); __iormb(); __v; })
--
1.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: fix write*() I/O accessors
Le 11/02/2011 23:25, Wolfgang Denk a écrit : Commit 3c0659b ARM: Avoid compiler optimization for readb, writeb and friends. introduced I/O accessors with memory barriers. Unfortunately the new write*() accessors introduced a bug: The problem is that the argument v gets evaluated twice. This breaks code like used here (from drivers/net/dnet.c): for (i = 0; i wrsz; i++) writel(*bufp++,dnet-regs-TX_DATA_FIFO); Use auxiliary variables to avoid such problems. Signed-off-by: Wolfgang Denkw...@denx.de Cc: Albert Aribaudalbert.arib...@free.fr Cc: Alexander Hollerhol...@ahsoftware.de Cc: Dirk Behmedirk.be...@googlemail.com --- This patch fixes a pretty nasty problem. Everybody who has experienced strange failures on ARM lately should apply it ASAP and re-test. As far as I can tell at least the following drivers are affected: drivers/net/dnet.c: writel(*bufp++,dnet-regs-TX_DATA_FIFO); drivers/usb/musb/musb_core.c: writeb(*data++,musbr-fifox[ep]); drivers/mmc/pxa_mmc.c:writel(*src++, MMC_TXFIFO); drivers/mmc/mxcmmc.c: writel(*buf++,host-base-buffer_access); drivers/spi/davinci_spi.c:writel(data1_reg_val | *txp++,ds-regs-dat1); Albert, please apply ASAP! Applied, available on u-boot-arm/master. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] mkimage: add -V option to print version information
Dear Albert ARIBAUD, In message 4d55b03a.9030...@free.fr you wrote: Please ignore my previous post on V1, I had not seen V2. My comment holds, though: ... + case 'V': + printf(mkimage version %s\n, + U_BOOT_VERSION + 7); If that magic number 7 (and the addition, as well) has any reason, it should at least be explained in a short comment. Heh... I though I could leave this as an exercide for the reader ;-) New version following... Thanks for pointing out. 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 hottest places in Hell are reserved for those who, in times of moral crisis, preserved their neutrality.- Dante ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: fix write*() I/O accessors
Dear Albert ARIBAUD, In message 4d55b8c9.8070...@free.fr you wrote: This patch fixes a pretty nasty problem. Everybody who has experienced strange failures on ARM lately should apply it ASAP and re-test. As far as I can tell at least the following drivers are affected: drivers/net/dnet.c: writel(*bufp++,dnet-regs-TX_DATA_FIFO); drivers/usb/musb/musb_core.c: writeb(*data++,musbr-fifox[ep]); drivers/mmc/pxa_mmc.c: writel(*src++, MMC_TXFIFO); drivers/mmc/mxcmmc.c: writel(*buf++,host-base-buffer_access); drivers/spi/davinci_spi.c: writel(data1_reg_val | *txp++,ds-regs-dat1); Albert, please apply ASAP! Applied, available on u-boot-arm/master. Thanks, highly appreciated. 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 This is an unauthorized cybernetic announcement. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] mkimage: add -V option to print version information
Signed-off-by: Wolfgang Denk w...@denx.de --- v2: fix missing argument to printf() call. v3: explain the magic + 7 offset into the version string tools/mkimage.c | 11 +++ 1 files changed, 11 insertions(+), 0 deletions(-) diff --git a/tools/mkimage.c b/tools/mkimage.c index f5859d7..febb536 100644 --- a/tools/mkimage.c +++ b/tools/mkimage.c @@ -23,6 +23,7 @@ #include mkimage.h #include image.h +#include version.h static void copy_file(int, const char *, int); static void usage(void); @@ -246,6 +247,14 @@ main (int argc, char **argv) case 'v': params.vflag++; break; + case 'V': + /* +* Skip the U-Boot part in +* U_BOOT_VERSION by adding 7 +*/ + printf(mkimage version %s\n, + U_BOOT_VERSION + 7); + exit(EXIT_SUCCESS); case 'x': params.xflag++; break; @@ -590,6 +599,8 @@ usage () params.cmdname); fprintf (stderr,%s [-D dtc_options] -f fit-image.its fit-image\n, params.cmdname); + fprintf (stderr,%s -V == print version information and exit\n, + params.cmdname); exit (EXIT_FAILURE); } -- 1.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: fix write*() I/O accessors
Hello,
Am 11.02.2011 23:25, schrieb Wolfgang Denk:
+#define writeb(v,c) ({ u8 __v = v; __iowmb(); __arch_putb(__v,c); __v; })
+#define writew(v,c) ({ u16 __v = v; __iowmb(); __arch_putw(__v,c); __v; })
+#define writel(v,c) ({ u32 __v = v; __iowmb(); __arch_putl(__v,c); __v; })
Thanks a lot, can I have the do {} while() back? I still don't like such
macro-making-sense-only constructs. (Just kidding). ;)
Regards,
Alexander
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] mkimage: add -V option to print version information
On Fri, 11 Feb 2011 23:41:43 +0100 Wolfgang Denk w...@denx.de wrote: + case 'V': + /* + * Skip the U-Boot part in + * U_BOOT_VERSION by adding 7 + */ + printf(mkimage version %s\n, + U_BOOT_VERSION + 7); I'd have done it without magic nor comments as U_BOOT_VERSION[sizeof(U-Boot ) + 1] or even U_BOOT_VERSION[strlen(U-Boot )] Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/5] e1000: Restructure and streamline PCI device probing
By allocating the e1000 device structures much earlier, we can easily
generate better error messages and siginficantly clean things up.
The only user-visable change (aside from reworded error messages) is
that a detected e1000 device which fails to initialize due to software
or hardware error will still be allocated a device number.
As one example, consider a system with 2 e1000 PCI devices where the
first controller has a corrupted EEPROM. Using the old code the
second controller would be e1000#0, while with this change it would be
e1000#1.
This change should hopefully make such EEPROM errors much more
straightforward to handle correctly in boot scripts and the like.
It is also necessary for a followup patch which allows SPI programming
of an e1000 controller's EEPROM even if the checksum is invalid.
Signed-off-by: Kyle Moffett kyle.d.moff...@boeing.com
---
drivers/net/e1000.c | 117 +--
drivers/net/e1000.h |3 +
2 files changed, 60 insertions(+), 60 deletions(-)
diff --git a/drivers/net/e1000.c b/drivers/net/e1000.c
index 5383064..ddf29c8 100644
--- a/drivers/net/e1000.c
+++ b/drivers/net/e1000.c
@@ -65,7 +65,7 @@ static struct e1000_rx_desc *rx_base;
static int tx_tail;
static int rx_tail, rx_last;
-static struct pci_device_id supported[] = {
+static struct pci_device_id e1000_supported[] = {
{PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82542},
{PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82543GC_FIBER},
{PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82543GC_COPPER},
@@ -4746,7 +4746,7 @@ e1000_set_media_type(struct e1000_hw *hw)
**/
static int
-e1000_sw_init(struct eth_device *nic, int cardnum)
+e1000_sw_init(struct eth_device *nic)
{
struct e1000_hw *hw = (typeof(hw)) nic-priv;
int result;
@@ -5146,57 +5146,59 @@ You should omit the last argument struct pci_device *
for a non-PCI NIC
int
e1000_initialize(bd_t * bis)
{
+ unsigned int i;
pci_dev_t devno;
- int card_number = 0;
- struct eth_device *nic = NULL;
- struct e1000_hw *hw = NULL;
- u32 iobase;
- int idx = 0;
- u32 PciCommandWord;
DEBUGFUNC();
- while (1) { /* Find PCI device(s) */
- if ((devno = pci_find_devices(supported, idx++)) 0) {
- break;
- }
-
- pci_read_config_dword(devno, PCI_BASE_ADDRESS_0, iobase);
- iobase = ~0xf; /* Mask the bits that say this is an io addr
*/
- DEBUGOUT(e1000#%d: iobase 0x%08x\n, card_number, iobase);
-
- pci_write_config_dword(devno, PCI_COMMAND,
- PCI_COMMAND_MEMORY | PCI_COMMAND_MASTER);
- /* Check if I/O accesses and Bus Mastering are enabled. */
- pci_read_config_dword(devno, PCI_COMMAND, PciCommandWord);
- if (!(PciCommandWord PCI_COMMAND_MEMORY)) {
- printf(Error: Can not enable MEM access.\n);
- continue;
- } else if (!(PciCommandWord PCI_COMMAND_MASTER)) {
- printf(Error: Can not enable Bus Mastering.\n);
- continue;
- }
-
- nic = (struct eth_device *) malloc(sizeof (*nic));
- if (!nic) {
- printf(Error: e1000 - Can not alloc memory\n);
- return 0;
- }
+ /* Find and probe all the matching PCI devices */
+ for (i = 0; (devno = pci_find_devices(e1000_supported, i)) = 0; i++) {
+ u32 val;
- hw = (struct e1000_hw *) malloc(sizeof (*hw));
- if (!hw) {
+ /*
+* These will never get freed due to errors, this allows us to
+* perform SPI EEPROM programming from U-boot, for example.
+*/
+ struct eth_device *nic = malloc(sizeof(*nic));
+ struct e1000_hw *hw = malloc(sizeof(*hw));
+ if (!nic || !hw) {
+ printf(e1000#%u: Out of Memory!\n, i);
free(nic);
- printf(Error: e1000 - Can not alloc memory\n);
- return 0;
+ free(hw);
+ continue;
}
+ /* Make sure all of the fields are initially zeroed */
memset(nic, 0, sizeof(*nic));
memset(hw, 0, sizeof(*hw));
+ /* Assign the passed-in values */
+ hw-cardnum = i;
hw-pdev = devno;
+ hw-nic = nic;
nic-priv = hw;
- sprintf(nic-name, e1000#%d, card_number);
+ /* Generate a card name */
+ sprintf(nic-name, e1000#%u, hw-cardnum);
+
+ /* Print a debug message with the IO base address */
+ pci_read_config_dword(devno,
[U-Boot] [PATCH 4/5] e1000: New e1000 commands for SPI EEPROM management
For our new board ports, we are programming the EEPROMs attached to our
Intel 82571EB controllers from software (using U-Boot and Linux).
This code provides a helpful set of e1000 subcommands for performing
EEPROM manipulation on e1000 devices, including displaying a hex-dump,
copying to and from main memory, and verifying/updating of the software
checksum.
The following commands work for programming the EEPROM from USB:
usb start
fatload usb 0 $loadaddr 82571EB_No_Mgmt_Discrete-LOM.bin
e1000 0 eeprom program $loadaddr 0 1024
e1000 0 eeprom checksum update
Please keep in mind that the Intel-provided .eep files are organized as
16-bit words. When converting them to binary form for programming you
must byteswap each 16-bit word so that it is in little-endian form.
This means that when reading and writing words to the SPI EEPROM, the
bit ordering for each word looks like this on the wire:
Time
-
... [7, 6, 5, 4, 3, 2, 1, 0, 15, 14, 13, 12, 11, 10, 9, 8], ...
-
(MSB is 15, LSB is 0).
Signed-off-by: Kyle Moffett kyle.d.moff...@boeing.com
---
drivers/net/e1000.c | 533 ++-
drivers/net/e1000.h |2 +
2 files changed, 534 insertions(+), 1 deletions(-)
diff --git a/drivers/net/e1000.c b/drivers/net/e1000.c
index c4cedc6..b8bc27f 100644
--- a/drivers/net/e1000.c
+++ b/drivers/net/e1000.c
@@ -5153,6 +5153,8 @@ void e1000_get_bus_type(struct e1000_hw *hw)
}
}
+static LIST_HEAD(e1000_hw_list);
+
/**
PROBE - Look for an adapter, this routine's visible to the outside
You should omit the last argument struct pci_device * for a non-PCI NIC
@@ -5231,8 +5233,9 @@ e1000_initialize(bd_t * bis)
if (e1000_check_phy_reset_block(hw))
printf(%s: ERROR: PHY Reset is blocked!\n, nic-name);
- /* Basic init was OK, reset the hardware */
+ /* Basic init was OK, reset the hardware and allow SPI access */
e1000_reset_hw(hw);
+ list_add_tail(hw-list_node, e1000_hw_list);
/* Validate the EEPROM and get chipset information */
#if !(defined(CONFIG_AP1000) || defined(CONFIG_MVBC_1G))
@@ -5260,3 +5263,531 @@ e1000_initialize(bd_t * bis)
return i;
}
+
+#ifdef CONFIG_CMD_E1000
+static struct e1000_hw *e1000_find_card(unsigned int cardnum)
+{
+ struct e1000_hw *hw;
+
+ list_for_each_entry(hw, e1000_hw_list, list_node)
+ if (hw-cardnum == cardnum)
+ return hw;
+
+ return NULL;
+}
+
+/*---
+ * SPI transfer
+ *
+ * This writes bitlen bits out the SPI MOSI port and simultaneously clocks
+ * bitlen bits in the SPI MISO port. That's just the way SPI works.
+ *
+ * The source of the outgoing bits is the dout parameter and the
+ * destination of the input bits is the din parameter. Note that dout
+ * and din can point to the same memory location, in which case the
+ * input data overwrites the output data (since both are buffered by
+ * temporary variables, this is OK).
+ *
+ * This may be interrupted with Ctrl-C if intr is true, otherwise it will
+ * never return an error.
+ */
+static int e1000_spi_xfer(struct e1000_hw *hw, unsigned int bitlen,
+ const void *dout_mem, void *din_mem, boolean_t intr)
+{
+ const uint8_t *dout = dout_mem;
+ uint8_t *din = din_mem;
+
+ uint8_t mask = 0;
+ uint32_t eecd;
+ unsigned long i;
+
+ /* Pre-read the control register */
+ eecd = E1000_READ_REG(hw, EECD);
+
+ /* Iterate over each bit */
+ for (i = 0, mask = 0x80; i bitlen; i++, mask = (mask 1)?:0x80) {
+ /* Check for interrupt */
+ if (intr ctrlc())
+ return -1;
+
+ /* Determine the output bit */
+ if (dout dout[i 3] mask)
+ eecd |= E1000_EECD_DI;
+ else
+ eecd = ~E1000_EECD_DI;
+
+ /* Write the output bit and wait 50us */
+ E1000_WRITE_REG(hw, EECD, eecd);
+ E1000_WRITE_FLUSH(hw);
+ udelay(50);
+
+ /* Poke the clock (waits 50us) */
+ e1000_raise_ee_clk(hw, eecd);
+
+ /* Now read the input bit */
+ eecd = E1000_READ_REG(hw, EECD);
+ if (din) {
+ if (eecd E1000_EECD_DO)
+ din[i 3] |= mask;
+ else
+ din[i 3] = ~mask;
+ }
+
+ /* Poke the clock again (waits 50us) */
+ e1000_lower_ee_clk(hw, eecd);
+ }
+
+ /* Now clear any remaining bits of the
[U-Boot] e1000: Driver additions for eXMeritus HWW-1U-1A
Sorry for taking so long to update and re-post these; I've had a lot of other things on my plate for the last several months. I've re-based them against the latest U-Boot master branch as of today. The following 5 patches are a series to provide the necessary support for the onboard Intel 82571 E1000E chips on our eXMeritus HWW-1U-1A boards. There are a few incidental fixups for dual-port NICs, but the main body of these patches is an SPI driver and e1000 eeprom commands for programming the configuration EEPROM attached to the 82571 chips. Our manufacturing process directly attaches the unprogrammed EEPROMs to the boards. We then use this code to load the Intel EEPROM and update the MAC address. The overall diffstat is: drivers/net/e1000.c | 848 --- drivers/net/e1000.h | 18 +- 2 files changed, 751 insertions(+), 115 deletions(-) Most of the new code is hidden behind a couple of config options, so it won't affect other users of e1000 chips unless they explicitly request it. Cheers, Kyle Moffett ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/5] e1000: Clean up handling of dual-port NICs and support 82571
Consolidate the test for a dual-port NIC to one location for easy
modification, then fix support for the dual-port 82571.
Signed-off-by: Kyle Moffett kyle.d.moff...@boeing.com
---
drivers/net/e1000.c | 66 +-
drivers/net/e1000.h |6
2 files changed, 33 insertions(+), 39 deletions(-)
diff --git a/drivers/net/e1000.c b/drivers/net/e1000.c
index 5f390bd..5383064 100644
--- a/drivers/net/e1000.c
+++ b/drivers/net/e1000.c
@@ -1096,6 +1096,20 @@ e1000_swfw_sync_acquire(struct e1000_hw *hw, uint16_t
mask)
return E1000_SUCCESS;
}
+static boolean_t e1000_is_second_port(struct e1000_hw *hw)
+{
+ switch (hw-mac_type) {
+ case e1000_80003es2lan:
+ case e1000_82546:
+ case e1000_82571:
+ if (E1000_READ_REG(hw, STATUS) E1000_STATUS_FUNC_1)
+ return TRUE;
+ /* Fallthrough */
+ default:
+ return FALSE;
+ }
+}
+
/**
* Reads the adapter's MAC address from the EEPROM and inverts the LSB for the
* second function of dual function devices
@@ -1122,11 +1136,11 @@ e1000_read_mac_addr(struct eth_device *nic)
nic-enetaddr[i] = eeprom_data 0xff;
nic-enetaddr[i + 1] = (eeprom_data 8) 0xff;
}
- if ((hw-mac_type == e1000_82546)
- (E1000_READ_REG(hw, STATUS) E1000_STATUS_FUNC_1)) {
- /* Invert the last bit if this is the second device */
- nic-enetaddr[5] += 1;
- }
+
+ /* Invert the last bit if this is the second device */
+ if (e1000_is_second_port(hw))
+ nic-enetaddr[5] ^= 1;
+
#ifdef CONFIG_E1000_FALLBACK_MAC
if ( *(u32*)(nic-enetaddr) == 0 || *(u32*)(nic-enetaddr) == ~0 ) {
unsigned char fb_mac[NODE_ADDRESS_SIZE] =
CONFIG_E1000_FALLBACK_MAC;
@@ -2528,16 +2542,13 @@ e1000_check_mng_mode(struct e1000_hw *hw)
static int32_t
e1000_write_kmrn_reg(struct e1000_hw *hw, uint32_t reg_addr, uint16_t data)
{
+ uint16_t swfw = E1000_SWFW_PHY0_SM;
uint32_t reg_val;
- uint16_t swfw;
DEBUGFUNC();
- if ((hw-mac_type == e1000_80003es2lan)
- (E1000_READ_REG(hw, STATUS) E1000_STATUS_FUNC_1)) {
+ if (e1000_is_second_port(hw))
swfw = E1000_SWFW_PHY1_SM;
- } else {
- swfw = E1000_SWFW_PHY0_SM;
- }
+
if (e1000_swfw_sync_acquire(hw, swfw))
return -E1000_ERR_SWFW_SYNC;
@@ -2552,16 +2563,13 @@ e1000_write_kmrn_reg(struct e1000_hw *hw, uint32_t
reg_addr, uint16_t data)
static int32_t
e1000_read_kmrn_reg(struct e1000_hw *hw, uint32_t reg_addr, uint16_t *data)
{
+ uint16_t swfw = E1000_SWFW_PHY0_SM;
uint32_t reg_val;
- uint16_t swfw;
DEBUGFUNC();
- if ((hw-mac_type == e1000_80003es2lan)
- (E1000_READ_REG(hw, STATUS) E1000_STATUS_FUNC_1)) {
+ if (e1000_is_second_port(hw))
swfw = E1000_SWFW_PHY1_SM;
- } else {
- swfw = E1000_SWFW_PHY0_SM;
- }
+
if (e1000_swfw_sync_acquire(hw, swfw))
return -E1000_ERR_SWFW_SYNC;
@@ -4259,11 +4267,13 @@ e1000_get_phy_cfg_done(struct e1000_hw *hw)
default:
mdelay(10);
break;
+
case e1000_80003es2lan:
/* Separate *_CFG_DONE_* bit for each port */
- if (E1000_READ_REG(hw, STATUS) E1000_STATUS_FUNC_1)
+ if (e1000_is_second_port(hw))
cfg_mask = E1000_EEPROM_CFG_DONE_PORT_1;
- /* Fall Through */
+ /* Fall Through */
+
case e1000_82571:
case e1000_82572:
while (timeout) {
@@ -4292,10 +4302,10 @@ e1000_get_phy_cfg_done(struct e1000_hw *hw)
int32_t
e1000_phy_hw_reset(struct e1000_hw *hw)
{
+ uint16_t swfw = E1000_SWFW_PHY0_SM;
uint32_t ctrl, ctrl_ext;
uint32_t led_ctrl;
int32_t ret_val;
- uint16_t swfw;
DEBUGFUNC();
@@ -4308,16 +4318,14 @@ e1000_phy_hw_reset(struct e1000_hw *hw)
DEBUGOUT(Resetting Phy...\n);
if (hw-mac_type e1000_82543) {
- if ((hw-mac_type == e1000_80003es2lan)
- (E1000_READ_REG(hw, STATUS) E1000_STATUS_FUNC_1)) {
+ if (e1000_is_second_port(hw))
swfw = E1000_SWFW_PHY1_SM;
- } else {
- swfw = E1000_SWFW_PHY0_SM;
- }
+
if (e1000_swfw_sync_acquire(hw, swfw)) {
DEBUGOUT(Unable to acquire swfw sync\n);
return -E1000_ERR_SWFW_SYNC;
}
+
/* Read the device control register and assert the
E1000_CTRL_PHY_RST
* bit. Then, take it out of reset.
*/
@@ -4771,14 +4779,6 @@ e1000_sw_init(struct eth_device
[U-Boot] [PATCH 5/5] e1000: Add a small SPI driver wrapper around the EEPROM code
To make it possible to use the sspi command with the e1000 firmware
EEPROM we add a small generic SPI driver wrapper around the existing
e1000 SPI backend.
Signed-off-by: Kyle Moffett kyle.d.moff...@boeing.com
---
drivers/net/e1000.c | 92 ++-
drivers/net/e1000.h |7
2 files changed, 98 insertions(+), 1 deletions(-)
diff --git a/drivers/net/e1000.c b/drivers/net/e1000.c
index b8bc27f..e841bc9 100644
--- a/drivers/net/e1000.c
+++ b/drivers/net/e1000.c
@@ -5264,7 +5264,7 @@ e1000_initialize(bd_t * bis)
return i;
}
-#ifdef CONFIG_CMD_E1000
+#if defined(CONFIG_E1000_SPI) || defined(CONFIG_CMD_E1000)
static struct e1000_hw *e1000_find_card(unsigned int cardnum)
{
struct e1000_hw *hw;
@@ -5343,6 +5343,96 @@ static int e1000_spi_xfer(struct e1000_hw *hw, unsigned
int bitlen,
return 0;
}
+#endif /* defined(CONFIG_E1000_SPI) || defined(CONFIG_CMD_E1000) */
+
+#ifdef CONFIG_E1000_SPI
+static inline struct e1000_hw *e1000_hw_from_spi(struct spi_slave *spi)
+{
+ return container_of(spi, struct e1000_hw, spi);
+}
+
+/* Not sure why all of these are necessary */
+void spi_init_r(void) { /* Nothing to do */ }
+void spi_init_f(void) { /* Nothing to do */ }
+void spi_init(void) { /* Nothing to do */ }
+
+struct spi_slave *spi_setup_slave(unsigned int bus, unsigned int cs,
+ unsigned int max_hz, unsigned int mode)
+{
+ /* Find the right PCI device */
+ struct e1000_hw *hw = e1000_find_card(bus);
+ if (!hw) {
+ printf(ERROR: No such e1000 device: e1000#%u\n, bus);
+ return NULL;
+ }
+
+ /* Make sure it has an SPI chip */
+ if (hw-eeprom.type != e1000_eeprom_spi) {
+ printf(%s: No attached SPI EEPROM found!\n, hw-nic-name);
+ return NULL;
+ }
+
+ /* Argument sanity checks */
+ if (cs != 0) {
+ printf(%s: No such SPI chip: %u\n, hw-nic-name, cs);
+ return NULL;
+ }
+ if (mode != SPI_MODE_0) {
+ printf(%s: Cannot support SPI modes other than MODE-0\n,
+ hw-nic-name);
+ return NULL;
+ }
+
+ /* TODO: Use max_hz somehow */
+ printf(%s: EEPROM SPI access requested\n, hw-nic-name);
+ return hw-spi;
+}
+
+void spi_free_slave(struct spi_slave *spi)
+{
+ struct e1000_hw *hw = e1000_hw_from_spi(spi);
+ printf(%s: EEPROM SPI access released\n, hw-nic-name);
+}
+
+int spi_claim_bus(struct spi_slave *spi)
+{
+ struct e1000_hw *hw = e1000_hw_from_spi(spi);
+
+ if (e1000_acquire_eeprom(hw)) {
+ printf(%s: EEPROM SPI cannot be acquired!, hw-nic-name);
+ return -1;
+ }
+
+ return 0;
+}
+
+void spi_release_bus(struct spi_slave *spi)
+{
+ struct e1000_hw *hw = e1000_hw_from_spi(spi);
+ e1000_release_eeprom(hw);
+}
+
+/* Skinny wrapper around e1000_spi_xfer */
+int spi_xfer(struct spi_slave *spi, unsigned int bitlen,
+ const void *dout_mem, void *din_mem, unsigned long flags)
+{
+ struct e1000_hw *hw = e1000_hw_from_spi(spi);
+ int ret;
+
+ if (flags SPI_XFER_BEGIN)
+ e1000_standby_eeprom(hw);
+
+ ret = e1000_spi_xfer(hw, bitlen, dout_mem, din_mem, TRUE);
+
+ if (flags SPI_XFER_END)
+ e1000_standby_eeprom(hw);
+
+ return ret;
+}
+
+#endif /* CONFIG_E1000_SPI */
+
+#ifdef CONFIG_CMD_E1000
/* The EEPROM opcodes */
#define SPI_EEPROM_ENABLE_WR 0x06
diff --git a/drivers/net/e1000.h b/drivers/net/e1000.h
index 68a3409..f504c90 100644
--- a/drivers/net/e1000.h
+++ b/drivers/net/e1000.h
@@ -41,6 +41,10 @@
#include asm/io.h
#include pci.h
+#ifdef CONFIG_E1000_SPI
+#include spi.h
+#endif
+
#define E1000_ERR(args...) printf(e1000: args)
#ifdef E1000_DEBUG
@@ -1046,6 +1050,9 @@ typedef enum {
struct e1000_hw {
struct list_head list_node;
struct eth_device *nic;
+#ifdef CONFIG_E1000_SPI
+ struct spi_slave spi;
+#endif
unsigned int cardnum;
pci_dev_t pdev;
--
1.7.2.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/5] e1000: Rewrite EEPROM checksum error to give more information
As an aide to debugging, we should print out the expected value of the
EEPROM checksum in addition to just saying that it is wrong.
Signed-off-by: Kyle Moffett kyle.d.moff...@boeing.com
---
drivers/net/e1000.c | 48 ++--
1 files changed, 30 insertions(+), 18 deletions(-)
diff --git a/drivers/net/e1000.c b/drivers/net/e1000.c
index ddf29c8..c4cedc6 100644
--- a/drivers/net/e1000.c
+++ b/drivers/net/e1000.c
@@ -873,29 +873,43 @@ e1000_read_eeprom(struct e1000_hw *hw, uint16_t offset,
* If the the sum of the 64 16 bit words is 0xBABA, the EEPROM's checksum is
* valid.
*/
-static int
-e1000_validate_eeprom_checksum(struct eth_device *nic)
+static int e1000_validate_eeprom_checksum(struct e1000_hw *hw)
{
- struct e1000_hw *hw = nic-priv;
- uint16_t checksum = 0;
- uint16_t i, eeprom_data;
+ uint16_t i, checksum, checksum_reg, *buf;
DEBUGFUNC();
- for (i = 0; i (EEPROM_CHECKSUM_REG + 1); i++) {
- if (e1000_read_eeprom(hw, i, 1, eeprom_data) 0) {
- DEBUGOUT(EEPROM Read Error\n);
- return -E1000_ERR_EEPROM;
- }
- checksum += eeprom_data;
+ /* Allocate a temporary buffer */
+ buf = malloc(sizeof(buf[0]) * (EEPROM_CHECKSUM_REG + 1));
+ if (!buf) {
+ printf(%s: ERROR: Unable to allocate EEPROM buffer!\n,
+ hw-nic-name);
+ return -E1000_ERR_EEPROM;
}
- if (checksum == (uint16_t) EEPROM_SUM) {
- return 0;
- } else {
- DEBUGOUT(EEPROM Checksum Invalid\n);
+ /* Read the EEPROM */
+ if (e1000_read_eeprom(hw, 0, EEPROM_CHECKSUM_REG + 1, buf) 0) {
+ printf(%s: ERROR: Unable to read EEPROM!\n,
+ hw-nic-name);
return -E1000_ERR_EEPROM;
}
+
+ /* Compute the checksum */
+ for (i = 0; i EEPROM_CHECKSUM_REG; i++)
+ checksum += buf[i];
+ checksum = ((uint16_t)EEPROM_SUM) - checksum;
+ checksum_reg = buf[i];
+
+ /* Verify it! */
+ if (checksum == checksum_reg)
+ return 0;
+
+ /* Hrm, verification failed, print an error */
+ printf(%s: ERROR: EEPROM checksum is incorrect!\n, hw-nic-name);
+ printf(%s: ERROR: ...register was 0x%04hx, calculated 0x%04hx\n,
+ hw-nic-name, checksum_reg, checksum);
+
+ return -E1000_ERR_EEPROM;
}
/*
@@ -5226,10 +5240,8 @@ e1000_initialize(bd_t * bis)
printf(%s: ERROR: EEPROM is invalid!\n, nic-name);
continue;
}
- if (e1000_validate_eeprom_checksum(nic) 0) {
- printf(%s: ERROR: EEPROM checksum is bad!\n,
nic-name);
+ if (e1000_validate_eeprom_checksum(hw))
continue;
- }
#endif
e1000_read_mac_addr(nic);
e1000_get_bus_type(hw);
--
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 1/1] NAND Re: mtdparts fails with NAND = 4GB - Second try
I think I found the problem. The cfi code does not work properly in x8 mode. In x8 mode, according to the datasheet, the addresses should be doubled for all of the commands. Additionally, according to my correspondence with Spansion, there needs to be at least a 500ns delay after a reset command. The cfi code is incorrectly detecting the port width as FLASH_CFI_16BIT when it is actually 8-bits. Currently things just happen to work because the bus is being incorrectly detected as 16-bits, The 16-bit bus detection, however, breaks in x8 mode when it issues the commands for the manufacturer ID. In this case, the following takes place: In cmdset_amd_read_jedec_ids fwc addr 1f40 cmd f0 f0f0 16bit x 8 bit flash_write16: Wrote 0xf0f0 to address 1f40 funlock writing 0xaa to address 0xaaa fwc addr 1f401554 cmd aa 16bit x 8 bit flash_write16: Wrote 0x to address 1f401554 funlock writing 0xaa to address 0x555 fwc addr 1f400aaa cmd 55 16bit x 8 bit flash_write16: Wrote 0x to address 1f400aaa fwc addr 1f401554 cmd 90 9090 16bit x 8 bit flash_write16: Wrote 0x9090 to address 1f401554 flash_read8: Read 0x0 from address 1f41 flash_read8: Read 0x3f from address 1f43 This does not work. If the proper sequence is written, then it works fine. The proper sequence, according to the datasheet, is to do the following: write 0xf0 to address 0x write 0xaa to address 0xaaa write 0x55 to address 0x555 write 0x90 to address 0xaaa read address 0 (returns 1 as expected) read address 2 (returns 0x7e as expected) ... So the cfi code is broken in the x8 case. -Aaron Williams On Thursday, February 10, 2011 08:05:37 pm Aaron Williams wrote: On Thursday, February 10, 2011 07:27:12 pm Aaron Williams wrote: On Thursday, February 10, 2011 07:24:54 pm Aaron Williams wrote: On Thursday, February 10, 2011 07:08:01 am Andrew Dyer wrote: On Thu, Feb 10, 2011 at 00:28, Aaron Williams aaron.willi...@caviumnetworks.com wrote: I would suggest to make sure any caching/prefetching stuff is off, hardware is doing one flash bus access per CPU read/write. In cmdset_amd_read_jedec_ids() after this line: manuId = flash_read_uchar (info, FLASH_OFFSET_MANUFACTURER_ID); add something like printf(test manf id word = %04x\n, *(volatile uint16_t *)0x1f40); printf(test device id word = %04x\n, *(volatile uint16_t *)0x1f42); printf(test device id word = %04x\n, *(volatile uint16_t *)0x1f40001c); printf(test device id word = %04x\n, *(volatile uint16_t *)0x1f40001e); and see what you get. fwc addr 1f40 cmd f0 f0f0 16bit x 8 bit flash_write16: address: 1f40, value: 0xf0f0 fwc addr 1f401554 cmd aa 16bit x 8 bit flash_write16: address: 1f401554, value: 0x fwc addr 1f400aaa cmd 55 16bit x 8 bit flash_write16: address: 1f400aaa, value: 0x fwc addr 1f401554 cmd 90 9090 16bit x 8 bit flash_write16: address: 1f401554, value: 0x9090 flash_read8: address: 1f41, value: 0x0 test manf id word = 1000 test device id word = 013f test device id word = da6c test device id word = 2926 looks like garbage :-( What's in the flash at those addresses? Maybe something is happening to mess up the unlock sequence and you're reading the memory data instead of the device codes. It's odd that earlier in the sequence when the CFI query data is read the byte data is mirrored across both bytes of the response, here the two bytes are different. I received an email back from Spansion about this problem. They suggested that instead of the following: fwc addr 1f401554 cmd aa 16bit x 8 bit flash_write16: Wrote 0x to address 1f401554 funlock writing 0xaa to address 0x555 fwc addr 1f400aaa cmd 55 16bit x 8 bit flash_write16: Wrote 0x to address 1f400aaa fwc addr 1f401554 cmd 90 9090 16bit x 8 bit flash_write16: Wrote 0x9090 to address 1f401554 to instead do the following: write 0xAA to 0x1F400AAA write 0x55 to 0x1F400555 write 0x90 to 0x1F400AAA read 0x1F41
Re: [U-Boot] [U-BOOT] [PATCH] mmc: enable switch partition function
Hi, On Fri, Feb 11, 2011 at 11:05 PM, Lei Wen adrian.w...@gmail.com wrote: I am thinking now approach for this. How about adding addtitional member in the mmc structure, like part. During mmc probe, the driver could know whether the device support partition switch or not, if it support, we could register three other faked mmc device corresponding to two boot partition, and RPMB partition. Then we could use the current command to access the different hardware partition in the emmc. Like if we are accessing one hardware partition, we need to send switch command first. If the part member in the mmc is a invalid value, we then don't send that switch partition command. Could this approach be acceptable? Further refine this idea, don't need to call mmc_register multi-times. For the purpose is to switch partition when needed, we really do want to one real device. So I propose a new solution as: Assume there is two sd/mmc controller on the board, named as mmc0mmc1. The mmc0 attach with a sd card, and mmc1 attach with a emmc that has partition supported. Then we would have mmc(2, 3, 4, 5, 6, 7, 8) faked device map to mmc0 , mmc(9, 10, 11, 12, 13, 14, 15) map to mmc1. Give the command as mmc read 9 0x100 0 0x10, uboot would get the real device num by 9/7, while hardware part num is (9-1-7*real_dev_num) that is 1. So we need to make mmc1 send the switch part 1 command to the emmc, then perform the read operation. If we want to run mmc read 5 0x1 0x10 0x5, the sd attach on mmc0 has no hardware partition suppport, it would simply refuse to execute that command. Or if we want to be more gracefully handled, we could let the read 5 perform like the read 0 command. Any feedback for this?... Thanks, Lei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/32] x86: Fix definition of global_data struct for asm-offsets.c
On 04/02/11 23:35, Graeme Russ wrote: Signed-off-by: Graeme Russ graeme.r...@gmail.com --- arch/i386/include/asm/global_data.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Applied to u-boot-x86 Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 02/32] x86: Align config.mk and linker scripts with other arches
On 04/02/11 23:35, Graeme Russ wrote: Signed-off-by: Graeme Russ graeme.r...@gmail.com --- arch/i386/config.mk | 13 -- arch/i386/cpu/config.mk |4 +- arch/i386/cpu/u-boot.lds | 104 ++ board/eNET/config.mk |4 -- board/eNET/u-boot.lds| 104 -- 5 files changed, 114 insertions(+), 115 deletions(-) create mode 100644 arch/i386/cpu/u-boot.lds delete mode 100644 board/eNET/u-boot.lds Applied to u-boot-x86 (also added trivial removal of --cref) Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 03/32] eNET: Create distinct board configurations
On 04/02/11 23:35, Graeme Russ wrote: Position independant functionality is due for removal from the x86 architecture, so create two distinct configurations - One for Flash and one for SRAM Signed-off-by: Graeme Russ graeme.r...@gmail.com --- board/eNET/config.mk |1 - boards.cfg |3 ++- 2 files changed, 2 insertions(+), 2 deletions(-) Applied to u-boot-x86 Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 04/32] x86: Parametize values used in linker script
On 04/02/11 23:35, Graeme Russ wrote: Signed-off-by: Graeme Russ graeme.r...@gmail.com --- arch/i386/config.mk |1 + arch/i386/cpu/config.mk |6 ++ arch/i386/cpu/u-boot.lds | 24 arch/i386/lib/realmode.c |8 board/eNET/config.mk |1 + 5 files changed, 20 insertions(+), 20 deletions(-) Applied to u-boot-x86 Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 05/32] sc520: Sort Makefile
On 04/02/11 23:35, Graeme Russ wrote: Signed-off-by: Graeme Russ graeme.r...@gmail.com --- arch/i386/cpu/sc520/Makefile |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Applied to u-boot-x86 Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 05/32] sc520: Sort Makefile
On 04/02/11 23:35, Graeme Russ wrote: Signed-off-by: Graeme Russ graeme.r...@gmail.com --- arch/i386/cpu/sc520/Makefile |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Applied to u-boot-x86 Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 06/32] x86: Fix mangled umlauts
On 04/02/11 23:35, Graeme Russ wrote: git mergetool has a nasty habit of mangling umlats - fix ones that have been missed in previous submissions Signed-off-by: Graeme Russ graeme.r...@gmail.com --- arch/i386/cpu/start.S |2 +- arch/i386/lib/board.c |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) Applied to u-boot-x86 Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 07/32] x86: Add stack dump to register dump
On 04/02/11 23:35, Graeme Russ wrote: Signed-off-by: Graeme Russ graeme.r...@gmail.com --- arch/i386/cpu/interrupts.c | 16 1 files changed, 16 insertions(+), 0 deletions(-) Applied to u-boot-x86 Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 08/32] x86: Move Global Descriptor Table defines to processor.h
On 04/02/11 23:35, Graeme Russ wrote: Signed-off-by: Graeme Russ graeme.r...@gmail.com --- arch/i386/cpu/cpu.c |8 +--- arch/i386/include/asm/processor.h |9 ++--- 2 files changed, 7 insertions(+), 10 deletions(-) Applied to u-boot-x86 Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 09/32] x86: Add processor flags header from linux
On 04/02/11 23:35, Graeme Russ wrote: Signed-off-by: Graeme Russ graeme.r...@gmail.com --- arch/i386/cpu/cpu.c | 13 +++- arch/i386/cpu/interrupts.c |3 +- arch/i386/cpu/sc520/sc520.c |7 ++- arch/i386/cpu/start.S |3 +- arch/i386/cpu/start16.S |5 +- arch/i386/include/asm/processor-flags.h | 100 +++ 6 files changed, 121 insertions(+), 10 deletions(-) create mode 100644 arch/i386/include/asm/processor-flags.h Applied to u-boot-x86 Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 10/32] x86: Call early_board_init when warm booting
On 04/02/11 23:35, Graeme Russ wrote: early_board_init has been skipped to avoid SDRAM corruption in the case that a fully relocatable image has been loaded into SDRAM and is being executed from SDRAM. x86 is being aligned with other architectures (ARM and PPC in particlar) and will be using Cache-As-RAM to run a C environment from Flash (or SRAM if you have some). early_board_init may be needed to assist in the setup of Cache-As-RAM and the early C environment Signed-off-by: Graeme Russ graeme.r...@gmail.com --- arch/i386/cpu/start.S | 10 +- 1 files changed, 5 insertions(+), 5 deletions(-) Applied to u-boot-x86 Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 11/32] x86: Make cpu init functions weak
On 04/02/11 23:35, Graeme Russ wrote: Signed-off-by: Graeme Russ graeme.r...@gmail.com --- arch/i386/cpu/cpu.c | 14 -- arch/i386/cpu/sc520/sc520.c | 11 +++ arch/i386/include/asm/u-boot-i386.h |2 ++ board/eNET/eNET.c | 22 -- 4 files changed, 17 insertions(+), 32 deletions(-) Applied to u-boot-x86 Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 12/32] sc520: Define MMCR address in include file
On 04/02/11 23:35, Graeme Russ wrote: Signed-off-by: Graeme Russ graeme.r...@gmail.com --- arch/i386/cpu/sc520/sc520.c |2 +- arch/i386/cpu/sc520/sc520_asm.S | 49 - arch/i386/include/asm/ic/sc520.h | 36 ++- board/eNET/eNET_start16.S|7 +++-- 4 files changed, 55 insertions(+), 39 deletions(-) Applied to u-boot-x86 Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 13/32] sc520: Move board specific settings to board init function
On 04/02/11 23:35, Graeme Russ wrote: Signed-off-by: Graeme Russ graeme.r...@gmail.com --- arch/i386/cpu/sc520/sc520.c | 19 --- board/eNET/eNET.c |9 + 2 files changed, 9 insertions(+), 19 deletions(-) Applied to u-boot-x86 Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 14/32] sc520: Remove printf calls from cpu_init_f
On 04/02/11 23:35, Graeme Russ wrote: In later patches, cpu_init_f will be called before console has been initialised and printf will not be legitimately available Signed-off-by: Graeme Russ graeme.r...@gmail.com --- arch/i386/cpu/sc520/sc520.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) Applied to u-boot-x86 Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 15/32] eNET: Fix eNET Interrupt Setup for Linux
On 04/02/11 23:35, Graeme Russ wrote: Fix minor issues with the configuration of the hardware interrupts for Linux when booting the eNET board Signed-off-by: Graeme Russ graeme.r...@gmail.com --- board/eNET/eNET.c | 15 +-- 1 files changed, 9 insertions(+), 6 deletions(-) Applied to u-boot-x86 Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 16/32] eNET: Add RTC support to eNET
On 04/02/11 23:35, Graeme Russ wrote: The SC520 has an inbuilt MC146818 - Enable it for the eNET board Signed-off-by: Graeme Russ graeme.r...@gmail.com --- drivers/rtc/mc146818.c |6 ++ include/configs/eNET.h |2 ++ 2 files changed, 8 insertions(+), 0 deletions(-) Applied to u-boot-x86 Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 17/32] eNET: Define MMCR values in config.h
On 04/02/11 23:35, Graeme Russ wrote: Signed-off-by: Graeme Russ graeme.r...@gmail.com --- board/eNET/eNET.c | 104 +++- board/eNET/eNET_start16.S |5 +- include/configs/eNET.h| 382 + 3 files changed, 445 insertions(+), 46 deletions(-) Applied to u-boot-x86 Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 18/32] eNET: Rearrange PAR assignments
On 04/02/11 23:35, Graeme Russ wrote: Signed-off-by: Graeme Russ graeme.r...@gmail.com --- board/eNET/eNET.c | 61 --- include/configs/eNET.h | 15 --- 2 files changed, 46 insertions(+), 30 deletions(-) Applied to u-boot-x86 Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 20/32] x86: Move initial gd to fixed location
On 04/02/11 23:35, Graeme Russ wrote: Signed-off-by: Graeme Russ graeme.r...@gmail.com --- arch/i386/cpu/start.S | 12 +- arch/i386/include/asm/global_data.h |7 +- arch/i386/lib/board.c | 36 +++--- include/configs/eNET.h |3 ++ 4 files changed, 39 insertions(+), 19 deletions(-) Applied to u-boot-x86 Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 21/32] x86: Use Cache-As-RAM for initial stack
On 04/02/11 23:35, Graeme Russ wrote: Signed-off-by: Graeme Russ graeme.r...@gmail.com --- arch/i386/cpu/sc520/Makefile|1 + arch/i386/cpu/sc520/sc520_asm.S |6 +- arch/i386/cpu/sc520/sc520_car.S | 94 +++ arch/i386/cpu/start.S | 35 +++--- include/configs/eNET.h | 20 5 files changed, 135 insertions(+), 21 deletions(-) create mode 100644 arch/i386/cpu/sc520/sc520_car.S Applied to u-boot-x86 Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 22/32] sc520: Move RAM sizing code from asm to C
On 04/02/11 23:35, Graeme Russ wrote: Signed-off-by: Graeme Russ graeme.r...@gmail.com --- arch/i386/cpu/sc520/Makefile |2 +- arch/i386/cpu/sc520/sc520.c | 110 --- arch/i386/cpu/sc520/sc520_asm.S | 608 - arch/i386/cpu/sc520/sc520_sdram.c | 532 arch/i386/cpu/start.S | 48 +-- arch/i386/include/asm/ic/sc520.h | 57 arch/i386/lib/board.c | 10 +- board/eNET/eNET.c |6 - board/eNET/eNET_start16.S |5 - include/configs/eNET.h|2 +- 10 files changed, 612 insertions(+), 768 deletions(-) delete mode 100644 arch/i386/cpu/sc520/sc520_asm.S create mode 100644 arch/i386/cpu/sc520/sc520_sdram.c Applied to u-boot-x86 Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 23/32] x86: Defer setup of final stack
On 04/02/11 23:35, Graeme Russ wrote: Signed-off-by: Graeme Russ graeme.r...@gmail.com --- arch/i386/cpu/start.S | 44 +--- arch/i386/lib/board.c |6 -- 2 files changed, 33 insertions(+), 17 deletions(-) Applied to u-boot-x86 Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 24/32] x86: Move call to dram_init_f into board_init_f
On 04/02/11 23:35, Graeme Russ wrote: Signed-off-by: Graeme Russ graeme.r...@gmail.com --- arch/i386/cpu/start.S |3 --- arch/i386/include/asm/u-boot-i386.h |1 + arch/i386/lib/board.c |3 +++ 3 files changed, 4 insertions(+), 3 deletions(-) Applied to u-boot-x86 Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 26/32] x86: Move console initialisation into board_init_f
On 04/02/11 23:35, Graeme Russ wrote: Signed-off-by: Graeme Russ graeme.r...@gmail.com --- arch/i386/lib/board.c | 15 --- 1 files changed, 12 insertions(+), 3 deletions(-) Applied to u-boot-x86 Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 28/32] x86: Split board_init_f() into init_fnc_t compatible functions
On 04/02/11 23:35, Graeme Russ wrote: Signed-off-by: Graeme Russ graeme.r...@gmail.com --- arch/i386/include/asm/global_data.h | 12 +++- arch/i386/lib/board.c | 111 +-- 2 files changed, 74 insertions(+), 49 deletions(-) Applied to u-boot-x86 Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 29/32] x86: Rearrange function calls in board_init_f
On 04/02/11 23:35, Graeme Russ wrote: Signed-off-by: Graeme Russ graeme.r...@gmail.com --- arch/i386/lib/board.c | 16 1 files changed, 8 insertions(+), 8 deletions(-) Applied to u-boot-x86 Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 30/32] x86: Convert board_init_f to use an init_sequence
On 04/02/11 23:35, Graeme Russ wrote: Signed-off-by: Graeme Russ graeme.r...@gmail.com --- arch/i386/lib/board.c | 70 1 files changed, 29 insertions(+), 41 deletions(-) Applied to u-boot-x86 Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
