Re: [U-Boot] Pull request - microblaze
Dear Michal Simek, In message 4d5b70de.6070...@monstr.eu you wrote: are available in the git repository at: git://www.denx.de/git/u-boot-microblaze.git master ... Which branch should I pull from? I guess you mean u-boot-microblaze.git #master ? It was above. Oops. Sorry for the noise. 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. -- H. L. Mencken ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] at91 spi bus speed
So the 10MHz is a safe value I guess. But I was wondering most why the bus speed seems to be limited to ~12MHz. Is that a limitation of the at91sam9g20 or more likely a problem with the board design? On Tue, Feb 15, 2011 at 9:08 PM, Mike Frysinger vap...@gentoo.org wrote: On Tuesday, February 15, 2011 06:56:42 wouter moors wrote: I saw that in env_sf.c that the spi bus speed is set at 10 MHz and was wondering if there was a specific reason for that? you mean it defaults to 10 MHz. boards can freely pick anything they want. some speed needed to be arbitrarily picked, and 10 MHz should work with every spi flash out there. -mike -- there's only 10 kinds of people. The ones that understand binary and the ones that don't. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] arm: get_sp() should always be compiled
From: Po-Yu Chuang ratb...@faraday-tech.com
get_sp() was incorrectly excluded if none of
CONFIG_SETUP_MEMORY_TAGS
CONFIG_CMDLINE_TAG
CONFIG_INITRD_TAG
CONFIG_SERIAL_TAG
CONFIG_REVISION_TAG
were defined.
Signed-off-by: Po-Yu Chuang ratb...@faraday-tech.com
---
v2:
rebase
arch/arm/lib/bootm.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
index a1649ee..7734953 100644
--- a/arch/arm/lib/bootm.c
+++ b/arch/arm/lib/bootm.c
@@ -327,12 +327,12 @@ void setup_revision_tag(struct tag **in_params)
}
#endif /* CONFIG_REVISION_TAG */
-
static void setup_end_tag (bd_t *bd)
{
params-hdr.tag = ATAG_NONE;
params-hdr.size = 0;
}
+#endif /* CONFIG_SETUP_MEMORY_TAGS || CONFIG_CMDLINE_TAG || CONFIG_INITRD_TAG
*/
static ulong get_sp(void)
{
@@ -341,5 +341,3 @@ static ulong get_sp(void)
asm(mov %0, sp : =r(ret) : );
return ret;
}
-
-#endif /* CONFIG_SETUP_MEMORY_TAGS || CONFIG_CMDLINE_TAG || CONFIG_INITRD_TAG
*/
--
1.6.3.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] ftpmu010: support faraday ftpmu010 driver
Hi Macpaul, On Wed, Feb 16, 2011 at 3:58 PM, Macpaul Lin macp...@gmail.com wrote: As you can see, the include of PMU header has been replaced to a correct path. [U-Boot,2/3] fttmr010: move fttmr010 controller to drivers/timer folder http://patchwork.ozlabs.org/patch/71952/ However, I cannot found the part of previous patch [U-Boot,1/3] You can find that I have replace a correct path to the file arch/arm/cpu/arm920t/a320/timer.c which haven't been applied. http://www.mail-archive.com/u-boot@lists.denx.de/msg41320.html Wolfgang, could you please check if something have been missing in the last git apply? It looks like that we have something missed in the current tree while this patch have been already applied http://www.mail-archive.com/u-boot@lists.denx.de/msg41320.html;. The missing part is the following patch. diff --git a/arch/arm/cpu/arm920t/a320/timer.c b/arch/arm/cpu/arm920t/a320/timer.c index d2e316f..4718ae6 100644 --- a/arch/arm/cpu/arm920t/a320/timer.c +++ b/arch/arm/cpu/arm920t/a320/timer.c @@ -19,7 +19,7 @@ #include common.h #include asm/io.h -#include asm/arch/ftpmu010.h +#include ../../../../../drivers/power/ftpmu010.h #include asm/arch/fttmr010.h static ulong timestamp; If I remember correctly, this patch was not applied because Wolfgang does not like the include ../../../... Po-Yu, Yes, there are also another patches waiting to be review and be applied. ftpmu010: fix relocation and enhance features http://patchwork.ozlabs.org/patch/77704/ This patch doesn't seem to affect a320. Since I have a patch to fix the current (compilation) problem, I'll send it to RFC. regards, Po-Yu Chuang ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] power: ftpmu010: move drivers/power/ftpmu010.h to include/
From: Po-Yu Chuang ratb...@faraday-tech.com
Also add API declarations.
Signed-off-by: Po-Yu Chuang ratb...@faraday-tech.com
---
drivers/power/ftpmu010.c |2 +-
drivers/power/ftpmu010.h | 146
include/ftpmu010.h | 150 ++
3 files changed, 151 insertions(+), 147 deletions(-)
delete mode 100644 drivers/power/ftpmu010.h
create mode 100644 include/ftpmu010.h
diff --git a/drivers/power/ftpmu010.c b/drivers/power/ftpmu010.c
index 7924ac1..dc4ca5d 100644
--- a/drivers/power/ftpmu010.c
+++ b/drivers/power/ftpmu010.c
@@ -23,7 +23,7 @@
#include common.h
#include asm/io.h
-#include ftpmu010.h
+#include ftpmu010.h
static struct ftpmu010 *pmu = (struct ftpmu010 *)CONFIG_FTPMU010_BASE;
diff --git a/drivers/power/ftpmu010.h b/drivers/power/ftpmu010.h
deleted file mode 100644
index 8ef7a37..000
--- a/drivers/power/ftpmu010.h
+++ /dev/null
@@ -1,146 +0,0 @@
-/*
- * (C) Copyright 2009 Faraday Technology
- * Po-Yu Chuang ratb...@faraday-tech.com
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
- */
-
-/*
- * Power Management Unit
- */
-#ifndef __FTPMU010_H
-#define __FTPMU010_H
-
-struct ftpmu010 {
- unsigned intIDNMBR0;/* 0x00 */
- unsigned intreserved0; /* 0x04 */
- unsigned intOSCC; /* 0x08 */
- unsigned intPMODE; /* 0x0C */
- unsigned intPMCR; /* 0x10 */
- unsigned intPED;/* 0x14 */
- unsigned intPEDSR; /* 0x18 */
- unsigned intreserved1; /* 0x1C */
- unsigned intPMSR; /* 0x20 */
- unsigned intPGSR; /* 0x24 */
- unsigned intMFPSR; /* 0x28 */
- unsigned intMISC; /* 0x2C */
- unsigned intPDLLCR0;/* 0x30 */
- unsigned intPDLLCR1;/* 0x34 */
- unsigned intAHBMCLKOFF; /* 0x38 */
- unsigned intAPBMCLKOFF; /* 0x3C */
- unsigned intDCSRCR0;/* 0x40 */
- unsigned intDCSRCR1;/* 0x44 */
- unsigned intDCSRCR2;/* 0x48 */
- unsigned intSDRAMHTC; /* 0x4C */
- unsigned intPSPR0; /* 0x50 */
- unsigned intPSPR1; /* 0x54 */
- unsigned intPSPR2; /* 0x58 */
- unsigned intPSPR3; /* 0x5C */
- unsigned intPSPR4; /* 0x60 */
- unsigned intPSPR5; /* 0x64 */
- unsigned intPSPR6; /* 0x68 */
- unsigned intPSPR7; /* 0x6C */
- unsigned intPSPR8; /* 0x70 */
- unsigned intPSPR9; /* 0x74 */
- unsigned intPSPR10; /* 0x78 */
- unsigned intPSPR11; /* 0x7C */
- unsigned intPSPR12; /* 0x80 */
- unsigned intPSPR13; /* 0x84 */
- unsigned intPSPR14; /* 0x88 */
- unsigned intPSPR15; /* 0x8C */
- unsigned intAHBDMA_RACCS; /* 0x90 */
- unsigned intreserved2; /* 0x94 */
- unsigned intreserved3; /* 0x98 */
- unsigned intJSS;/* 0x9C */
- unsigned intCFC_RACC; /* 0xA0 */
- unsigned intSSP1_RACC; /* 0xA4 */
- unsigned intUART1TX_RACC; /* 0xA8 */
- unsigned intUART1RX_RACC; /* 0xAC */
- unsigned intUART2TX_RACC; /* 0xB0 */
- unsigned intUART2RX_RACC; /* 0xB4 */
- unsigned intSDC_RACC; /* 0xB8 */
- unsigned intI2SAC97_RACC; /* 0xBC */
- unsigned intIRDATX_RACC;/* 0xC0 */
- unsigned intreserved4; /* 0xC4 */
- unsigned intUSBD_RACC; /* 0xC8 */
- unsigned intIRDARX_RACC;/* 0xCC */
- unsigned intIRDA_RACC; /* 0xD0 */
- unsigned intED0_RACC; /* 0xD4 */
- unsigned intED1_RACC; /* 0xD8 */
-};
-
-/*
- * ID Number 0 Register
- */
-#define FTPMU010_ID_A320A 0x0320
-#define FTPMU010_ID_A320C 0x03200010
-#define FTPMU010_ID_A320D 0x03200030
-
-/*
- * OSC Control Register
- */
-#define FTPMU010_OSCC_OSCH_TRI (1 11)
-#define FTPMU010_OSCC_OSCH_STABLE (1 9)
-#define
[U-Boot] [PATCH 2/2] arm: a320: use new ftpmu010 API
From: Po-Yu Chuang ratb...@faraday-tech.com ftpmu010 related code has been moved to drivers/power/. Signed-off-by: Po-Yu Chuang ratb...@faraday-tech.com --- arch/arm/cpu/arm920t/a320/timer.c | 22 +++--- include/configs/a320evb.h |5 + 2 files changed, 8 insertions(+), 19 deletions(-) diff --git a/arch/arm/cpu/arm920t/a320/timer.c b/arch/arm/cpu/arm920t/a320/timer.c index d2e316f..e261a49 100644 --- a/arch/arm/cpu/arm920t/a320/timer.c +++ b/arch/arm/cpu/arm920t/a320/timer.c @@ -19,14 +19,13 @@ #include common.h #include asm/io.h -#include asm/arch/ftpmu010.h +#include ftpmu010.h #include asm/arch/fttmr010.h static ulong timestamp; static ulong lastdec; static struct fttmr010 *tmr = (struct fttmr010 *)CONFIG_FTTMR010_BASE; -static struct ftpmu010 *pmu = (struct ftpmu010 *)CONFIG_FTPMU010_BASE; #define TIMER_CLOCK32768 #define TIMER_LOAD_VAL 0x @@ -41,23 +40,8 @@ int timer_init(void) /* disable timers */ writel(0, tmr-cr); - /* -* use 32768Hz oscillator for RTC, WDT, TIMER -*/ - - /* enable the 32768Hz oscillator */ - oscc = readl(pmu-OSCC); - oscc = ~(FTPMU010_OSCC_OSCL_OFF | FTPMU010_OSCC_OSCL_TRI); - writel(oscc, pmu-OSCC); - - /* wait until ready */ - while (!(readl(pmu-OSCC) FTPMU010_OSCC_OSCL_STABLE)) - ; - - /* select 32768Hz oscillator */ - oscc = readl(pmu-OSCC); - oscc |= FTPMU010_OSCC_OSCL_RTCLSEL; - writel(oscc, pmu-OSCC); + /* use 32768Hz oscillator for RTC, WDT, TIMER */ + ftpmu010_32768osc_enable(); /* setup timer */ writel(TIMER_LOAD_VAL, tmr-timer3_load); diff --git a/include/configs/a320evb.h b/include/configs/a320evb.h index 27f137f..5373bcb 100644 --- a/include/configs/a320evb.h +++ b/include/configs/a320evb.h @@ -32,6 +32,11 @@ #undef CONFIG_SKIP_LOWLEVEL_INIT /*--- + * Power Management Unit + */ +#define CONFIG_FTPMU010_POWER + +/*--- * Timer */ #define CONFIG_SYS_HZ 1000/* timer ticks per second */ -- 1.6.3.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] ftpmu010: support faraday ftpmu010 driver
Hi Po-Yu, 2011/2/16 Po-Yu Chuang ratbert.chu...@gmail.com: Hi Macpaul, On Wed, Feb 16, 2011 at 3:58 PM, Macpaul Lin macp...@gmail.com wrote: As you can see, the include of PMU header has been replaced to a correct path. [U-Boot,2/3] fttmr010: move fttmr010 controller to drivers/timer folder http://patchwork.ozlabs.org/patch/71952/ However, I cannot found the part of previous patch [U-Boot,1/3] You can find that I have replace a correct path to the file arch/arm/cpu/arm920t/a320/timer.c which haven't been applied. http://www.mail-archive.com/u-boot@lists.denx.de/msg41320.html Wolfgang, could you please check if something have been missing in the last git apply? It looks like that we have something missed in the current tree while this patch have been already applied http://www.mail-archive.com/u-boot@lists.denx.de/msg41320.html;. The missing part is the following patch. diff --git a/arch/arm/cpu/arm920t/a320/timer.c b/arch/arm/cpu/arm920t/a320/timer.c index d2e316f..4718ae6 100644 --- a/arch/arm/cpu/arm920t/a320/timer.c +++ b/arch/arm/cpu/arm920t/a320/timer.c @@ -19,7 +19,7 @@ #include common.h #include asm/io.h -#include asm/arch/ftpmu010.h +#include ../../../../../drivers/power/ftpmu010.h #include asm/arch/fttmr010.h static ulong timestamp; If I remember correctly, this patch was not applied because Wolfgang does not like the include ../../../... Yes. However, I also found there exists similar include format in other SoC. Even you put drivers for all common IP still have the same problem. For example, like some SoCs will use the drivers in board/Marvell/common/. If you want to use the API inside board/Marvell/common/, the code will looks like include ../../board/Marvell/common. Po-Yu, Yes, there are also another patches waiting to be review and be applied. ftpmu010: fix relocation and enhance features http://patchwork.ozlabs.org/patch/77704/ This patch doesn't seem to affect a320. Since I have a patch to fix the current (compilation) problem, I'll send it to RFC. Just one comment, I think you can put it into folder include/faraday I have discussed with Wolfgang about collecting the faraday header files together before. This should be better for future driver releasement. regards, Po-Yu Chuang -- Best regards, Macpaul Lin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] power: ftpmu010: move drivers/power/ftpmu010.h to include/
Hi Po-Yu, 2011/2/16 Po-Yu Chuang ratbert.chu...@gmail.com: From: Po-Yu Chuang ratb...@faraday-tech.com Also add API declarations. Signed-off-by: Po-Yu Chuang ratb...@faraday-tech.com --- drivers/power/ftpmu010.c | 2 +- drivers/power/ftpmu010.h | 146 include/ftpmu010.h | 150 ++ 3 files changed, 151 insertions(+), 147 deletions(-) delete mode 100644 drivers/power/ftpmu010.h create mode 100644 include/ftpmu010.h Just one comment which has been replied earlier in the previous discuss. Put ftpmu010.h into include/faraday instead of include. -- Best regards, Macpaul Lin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] power: ftpmu010: move drivers/power/ftpmu010.h to include/
Hi Macpaul, On Wed, Feb 16, 2011 at 5:23 PM, Macpaul Lin macp...@gmail.com wrote: Hi Po-Yu, 2011/2/16 Po-Yu Chuang ratbert.chu...@gmail.com: From: Po-Yu Chuang ratb...@faraday-tech.com Also add API declarations. Signed-off-by: Po-Yu Chuang ratb...@faraday-tech.com --- drivers/power/ftpmu010.c | 2 +- drivers/power/ftpmu010.h | 146 include/ftpmu010.h | 150 ++ 3 files changed, 151 insertions(+), 147 deletions(-) delete mode 100644 drivers/power/ftpmu010.h create mode 100644 include/ftpmu010.h Just one comment which has been replied earlier in the previous discuss. Put ftpmu010.h into include/faraday instead of include. Agree. It will be nicer. Wolfgang, do you have any comment? regards, Po-Yu Chuang ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request - microblaze
Wolfgang Denk wrote: Dear Michal Simek, In message 4d5b70de.6070...@monstr.eu you wrote: are available in the git repository at: git://www.denx.de/git/u-boot-microblaze.git master ... Which branch should I pull from? I guess you mean u-boot-microblaze.git #master ? It was above. Oops. Sorry for the noise. That's no problem. Thanks, Michal -- Michal Simek, Ing. (M.Eng) w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/ Microblaze U-BOOT custodian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] ftpmu010: support faraday ftpmu010 driver
Dear Po-Yu Chuang, In message AANLkTin5Od4_3W+YPTNP5tJAXKcayg+bjmdPP=+vi...@mail.gmail.com you wrote: -#include asm/arch/ftpmu010.h +#include ../../../../../drivers/power/ftpmu010.h #include asm/arch/fttmr010.h static ulong timestamp; If I remember correctly, this patch was not applied because Wolfgang does not like the include ../../../... Correct. 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 Compassion -- that's the one things no machine ever had. Maybe it's the one thing that keeps men ahead of them. -- McCoy, The Ultimate Computer, stardate 4731.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] ftpmu010: support faraday ftpmu010 driver
Dear Macpaul Lin, In message aanlktin8isrcnaq8hgnjdtgoa9uleicm7murdjz2z...@mail.gmail.com you wrote: If I remember correctly, this patch was not applied because Wolfgang does not like the include ../../../... Yes. However, I also found there exists similar include format in other SoC. Even you put drivers for all common IP still have the same problem. Bad examples is not an excuse for adding more bad code. Bad code may slip through a review, and sometimes it takes a while until we understand what is god or what is bad. But when we notice it, we reject it. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Space is big. You just won't believe how vastly, hugely, mind- bogglingly big it is. I mean, you may think it's a long way down the road to the drug store, but that's just peanuts to space. -- The Hitchhiker's Guide to the Galaxy ___ 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 Albert, On 2/13/2011 12:43 PM, Magnus Lilja wrote: On 02/12/2011 08:07 AM, Albert ARIBAUD wrote: Le 11/02/2011 19:58, Magnus Lilja a écrit : 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. Which is the ideal case for sending out a Tested-By: line. :) Tested-by: Magnus Lilja lilja.mag...@gmail.com Regards, Magnus Ping? Stefano has already applied the patches 2/3 and 3/3 from this series, but without 1/3 MX31PDK boot is still broken. Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Trouble with U-Boot on our EVM-based hardware
Hi Albert, Thank you for your reply. I also tried the U-Boot version for beagleboard, which comdes from git://www.denx.de/git/u-boot.git;protocol=git with revision ca6e1c136ddb720c3bb2cc043b99f7f06bc46c55 and a lot of patch files. Is this not the mainline? With this source (and my changes, but the problem is in common code) I also get my problem, and the data stored to gd/bd_t is lost unless it is volatile. Who is responsible for this part of code, who can help me with this problem in the common code? Maybe this maintainer: Manikandan Pillai mani.pil...@ti.com omap3_evm ARM CORTEX-A8 (OMAP3xx SoC) (file MAINTAINERS) Best regards, David. ___ David Schade, Software-Engineer, M. Eng. DResearch Digital Media Systems GmbH Otto-Schmirgal-Str. 3, D-10319 Berlin, Germany Tel: +49 (30) 515932 - 231 Fax: +49 (30) 515932 - 77 mailto: sch...@dresearch.de http://www.dresearch.de Amtsgericht: Berlin Charlottenburg, HRB:54412 Ust.-IDNr. DE169013825; WEEE Reg.-Nr. DE 85995642 Geschäftsführer: Dr. M. Weber, W. Mögle ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Problem booting on custom board (85xx)
Hello, I have a custom board based on the Freescale P2020 RDB. I am having trouble getting through the entire boot sequence. Basically, I can't get a breakpoint to hit in board_init_r. I can get a break point in the in_ram section of start.s though. This executes all the way to the following loop /* * Now adjust the fixups and the pointers to the fixups * in case we need to move ourselves again. */ li r0,__fixup_entries@sectoff@l lwz r3,GOT(_FIXUP_TABLE_) cmpwi r0,0 mtctr r0 addi r3,r3,-4 beq4f 3:lwzu ri4,4(r3) lwzuxr0,r4,r11 addr0,r0,r11 stw r10,0(r3) stw r0,0(r4) bdnz 3b Basically, it spins through this loop for a while and eventually I get a TLB exception. Is this just a cut and dry DDR configuration problem, or should I be looking at my Uboot setup? Thanks, Kevin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] building enc28j60 for omap3: undefined references
Hi all, I'm trying enabling enc2j60 in order to use tftp with SPI-Ethernet enc28j60 and beagleboard rev C3. When building u-boot some functions referred by enc28j60.c remain undefined. drivers/net/libnet.o: In function `enc28j60_initialize': u-boot/drivers/net/enc28j60.c:973: undefined reference to `eth_register' drivers/net/libnet.o: In function `enc_receive': u-boot/drivers/net/enc28j60.c:489: undefined reference to `NetReceive' drivers/net/libnet.o: In function `enc_recv': u-boot/drivers/net/enc28j60.c:868: undefined reference to `NetRxPackets' Driver gets compiled and linked without warnings nor errors: arm-angstrom-linux-gnueabi-gcc -g -Os -fno-common -ffixed-r8 -msoft-float -D__KERNEL__ -DCONFIG_SYS_TEXT_BASE=0x80008000 -Iu-boot/include -fno-builtin -ffreestanding -nostdinc -isystem cross/armv7a/lib/gcc/arm-angstrom-linux-gnueabi/4.3.1/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mabi=aapcs-linux -mno-thumb-interwork -march=armv5 -Wall -Wstrict-prototypes -fno-stack-protector -o enc28j60.o enc28j60.c -c arm-angstrom-linux-gnueabi-ld -r -o libnet.o enc28j60.o I'm using last u-boot, cloned from master branch yesterday. Is my toolchain broken? thank you j ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] ppc460ex NAND flash programming
I want to do NAND flash programming with u-boot-nand in a row board (Canyonlands PPC460Ex) , what is the solution? I changed TLB entries as SPL did, then loaded u-boot.bin (ram u-boot) into target's RAM using BDI-2000 (in order to use U-BOOT itself to do the programming) and issuing go command, it didn't work. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ppc460ex NAND flash programming
Hi Fawaz, On Wednesday 16 February 2011 17:48:06 Fawaz Gaili wrote: I want to do NAND flash programming with u-boot-nand in a row board (Canyonlands PPC460Ex) , what is the solution? I changed TLB entries as SPL did, then loaded u-boot.bin (ram u-boot) into target's RAM using BDI-2000 (in order to use U-BOOT itself to do the programming) and issuing go command, it didn't work. Your question is not really clear to me. Are you trying the NAND booting feature on the APM Canyonlands 460EX evaluation board? Or do you have a custom 460EX board without NOR flash, where you try to initially program the NAND flash? 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] building enc28j60 for omap3: undefined references
Dear jacopo mondi, Hi all, I'm trying enabling enc2j60 in order to use tftp with SPI-Ethernet enc28j60 and beagleboard rev C3. When building u-boot some functions referred by enc28j60.c remain undefined. drivers/net/libnet.o: In function `enc28j60_initialize': u-boot/drivers/net/enc28j60.c:973: undefined reference to `eth_register' drivers/net/libnet.o: In function `enc_receive': u-boot/drivers/net/enc28j60.c:489: undefined reference to `NetReceive' drivers/net/libnet.o: In function `enc_recv': u-boot/drivers/net/enc28j60.c:868: undefined reference to `NetRxPackets' ... I'm using last u-boot, cloned from master branch yesterday. Is my toolchain broken? Not sure, the driver builds fine with ARM boards. Maybe you need to have CONFIG_NET_MULTI set? Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Introduce a new linker flag LDFLAGS_FINAL
Dear Haiying Wang, In message 1297878184.1977.18.camel@haiying-laptop you wrote: I did run ./MAKEALL powerpc for all ppc board, the System.map and u-boot.map keep exactly the same before and after applying the LDFLAGS_FINAL patch. Please find the attached two txt files and System.map and u-boot.map which are the results of MAKEALL. Do you think I'm surrised that you send just one pair of these files. Does that mean that you did the compare only after the full MAKEALL run, i. e. just on the last result, for the last board? We have some 524 PowerPC configurations in boards.cfg, and the compare must be done for _all_ off these, i. e. there are 2 x 524 pairs of files to be compared. Did you really do this? it is ok to apply this patch, if you are ok with the name _FINAL? Others appear to be happy with it, and I don't have a better proposal, so let's use this _FINAL name. 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 All he had was nothing, but that was something, and now it had been taken away. - Terry Pratchett, _Sourcery_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Introduce a new linker flag LDFLAGS_FINAL
On Wed, 2011-02-16 at 19:29 +0100, Wolfgang Denk wrote: Dear Haiying Wang, In message 1297878184.1977.18.camel@haiying-laptop you wrote: I did run ./MAKEALL powerpc for all ppc board, the System.map and u-boot.map keep exactly the same before and after applying the LDFLAGS_FINAL patch. Please find the attached two txt files and System.map and u-boot.map which are the results of MAKEALL. Do you think I'm surrised that you send just one pair of these files. Does that mean that you did the compare only after the full MAKEALL run, i. e. just on the last result, for the last board? We have some 524 PowerPC configurations in boards.cfg, and the compare must be done for _all_ off these, i. e. there are 2 x 524 pairs of files to be compared. Did you really do this? it is ok to apply this patch, if you are ok with the name _FINAL? Sorry, I did not get the 2x254 pairs of System.map and u-boot.map. Running MAKEALL powerpc only left the last pair. Could you please show me how I can keep the former 523 pairs? Others appear to be happy with it, and I don't have a better proposal, so let's use this _FINAL name. Thanks. Haiying ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Introduce a new linker flag LDFLAGS_FINAL
Dear Haiying Wang,
In message 1297881643.1977.28.camel@haiying-laptop you wrote:
We have some 524 PowerPC configurations in boards.cfg, and the compare
must be done for _all_ off these, i. e. there are 2 x 524 pairs of
files to be compared. Did you really do this?
it is ok to apply this patch, if you are ok with the name _FINAL?
Sorry, I did not get the 2x254 pairs of System.map and u-boot.map. Running
MAKEALL powerpc only left the last pair. Could you please show me how I can
keep the former 523 pairs?
I usually do this on the fly using shell scripting capabilities, i.e.
something like this (copying some shell functions from MAKEALL):
---
boards_by_field()
{
awk \
-v field=$1 \
-v select=$2 \
'($1 !~ /^#/ $field == select) { print $1 }' \
boards.cfg
}
boards_by_arch() { boards_by_field 2 $@ ; }
for board in $(boards_by_arch powerpc) ; do
./MAKEALL $board
cp System.map System.map.${board}.unpatched
cp u-boot.map u-boot.map.${board}.unpatched
done
...apply patch...
for board in $(boards_by_arch powerpc) ; do
./MAKEALL $board
cmp System.map.${board}.unpatched System.map || diff -u
System.map.${board}.unpatched System.map System.map.${board}.diff
cmp u-boot.map.${board}.unpatched u-boot.map || diff -u
u-boot.map.${board}.unpatched u-boot.map u-boot.map.${board}.diff
done
less *.diff
---
Note this is untested; you probably get the idea.
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 1/2 V3] Add USB host ethernet adapter support
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 | 41 +++--
9 files changed, 298 insertions(+), 24 deletions(-)
create mode 100644 drivers/usb/eth/Makefile
create mode 100644 drivers/usb/eth/usb_ether.c
create mode 100644 include/usb_ether.h
diff --git a/Makefile b/Makefile
index 6133160..dc2e3d8 100644
--- a/Makefile
+++ b/Makefile
@@ -235,6 +235,7 @@ endif
LIBS += drivers/rtc/librtc.o
LIBS += drivers/serial/libserial.o
LIBS += drivers/twserial/libtws.o
+LIBS += drivers/usb/eth/libusb_eth.a
LIBS += drivers/usb/gadget/libusb_gadget.o
LIBS += drivers/usb/host/libusb_host.o
LIBS += drivers/usb/musb/libusb_musb.o
diff --git a/common/cmd_usb.c b/common/cmd_usb.c
index b04a8df..b5731a7 100644
--- a/common/cmd_usb.c
+++ b/common/cmd_usb.c
@@ -34,6 +34,9 @@
#ifdef CONFIG_USB_STORAGE
static int usb_stor_curr_dev = -1; /* current device */
#endif
+#ifdef CONFIG_USB_HOST_ETHER
+static int usb_ether_curr_dev = -1; /* current ethernet device */
+#endif
/* some display routines (info command) */
char *usb_get_class_desc(unsigned char dclass)
@@ -522,11 +525,16 @@ int do_usb(cmd_tbl_t *cmdtp, int flag, int argc, char *
const argv[])
usb_stop();
printf((Re)start USB...\n);
i = usb_init();
+ if (i = 0) {
#ifdef CONFIG_USB_STORAGE
- /* try to recognize storage devices immediately */
- if (i = 0)
+ /* try to recognize storage devices immediately */
usb_stor_curr_dev = usb_stor_scan(1);
#endif
+#ifdef CONFIG_USB_HOST_ETHER
+ /* try to recognize ethernet devices immediately */
+ usb_ether_curr_dev = usb_host_eth_scan(1);
+#endif
+ }
return 0;
}
if (strncmp(argv[1], stop, 4) == 0) {
diff --git a/common/usb.c b/common/usb.c
index 44a435a..4f7c520 100644
--- a/common/usb.c
+++ b/common/usb.c
@@ -145,10 +145,14 @@ int usb_stop(void)
/*
* disables the asynch behaviour of the control message. This is used for data
* transfers that uses the exclusiv access to the control and bulk messages.
+ * Returns the old value so it can be restored later.
*/
-void usb_disable_asynch(int disable)
+int usb_disable_asynch(int disable)
{
+ int old_value = asynch_allowed;
+
asynch_allowed = !disable;
+ return old_value;
}
diff --git a/doc/README.usb b/doc/README.usb
index b3bcb91..9aa4f62 100644
--- a/doc/README.usb
+++ b/doc/README.usb
@@ -28,7 +28,8 @@ USB Support for PIP405 and MIP405 (UHCI)
The USB support is implemented on the base of the UHCI Host
controller.
-Currently supported are USB Hubs, USB Keyboards and USB Floppys.
+Currently supported are USB Hubs, USB Keyboards, USB Floppys, USB
+flash sticks and USB network adaptors.
Tested with a TEAC Floppy TEAC FD-05PUB and Chicony KU-8933 Keyboard.
How it works:
@@ -78,3 +79,4 @@ CONFIG_USB_UHCI defines the lowlevel part.A
lowlevel part must be defined
if using CONFIG_CMD_USB
CONFIG_USB_KEYBOARD enables the USB Keyboard
CONFIG_USB_STORAGE enables the USB storage devices
+CONFIG_USB_HOST_ETHER enables USB ethernet dongle support
diff --git a/drivers/usb/eth/Makefile b/drivers/usb/eth/Makefile
new file mode 100644
index 000..a0f5676
--- /dev/null
+++ b/drivers/usb/eth/Makefile
@@ -0,0 +1,45 @@
+#
+# Copyright (c) 2011 The Chromium OS Authors.
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include
[U-Boot] [PATCH 2/2 V3] Add support for ASIX AX88772 USB 2.0 10/100Mbit Ethernet Adaptor
Driver originally written by NVIDIA Corporation, modified to
handle odd-length packets.
Signed-off-by: Simon Glass s...@chromium.org
---
drivers/usb/eth/Makefile|3 +
drivers/usb/eth/asix.c | 635 +++
drivers/usb/eth/usb_ether.c |7 +
include/usb_ether.h |7 +
4 files changed, 652 insertions(+), 0 deletions(-)
create mode 100644 drivers/usb/eth/asix.c
diff --git a/drivers/usb/eth/Makefile b/drivers/usb/eth/Makefile
index a0f5676..6a5f25a 100644
--- a/drivers/usb/eth/Makefile
+++ b/drivers/usb/eth/Makefile
@@ -25,6 +25,9 @@ LIB := $(obj)libusb_eth.a
# new USB host ethernet layer dependencies
COBJS-$(CONFIG_USB_HOST_ETHER) += usb_ether.o
+ifdef CONFIG_USB_ETHER_ASIX
+COBJS-y += asix.o
+endif
COBJS := $(COBJS-y)
SRCS := $(COBJS:.o=.c)
diff --git a/drivers/usb/eth/asix.c b/drivers/usb/eth/asix.c
new file mode 100644
index 000..9b012e4
--- /dev/null
+++ b/drivers/usb/eth/asix.c
@@ -0,0 +1,635 @@
+/*
+ * Copyright (c) 2011 The Chromium OS Authors.
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include common.h
+#include usb.h
+#include linux/mii.h
+#include usb_ether.h
+
+
+/* ASIX AX8817X based USB 2.0 Ethernet Devices */
+
+#define AX_CMD_SET_SW_MII 0x06
+#define AX_CMD_READ_MII_REG0x07
+#define AX_CMD_WRITE_MII_REG 0x08
+#define AX_CMD_SET_HW_MII 0x0a
+#define AX_CMD_READ_RX_CTL 0x0f
+#define AX_CMD_WRITE_RX_CTL0x10
+#define AX_CMD_WRITE_IPG0 0x12
+#define AX_CMD_READ_NODE_ID0x13
+#define AX_CMD_READ_PHY_ID 0x19
+#define AX_CMD_WRITE_MEDIUM_MODE 0x1b
+#define AX_CMD_WRITE_GPIOS 0x1f
+#define AX_CMD_SW_RESET0x20
+#define AX_CMD_SW_PHY_SELECT 0x22
+
+#define AX_SWRESET_CLEAR 0x00
+#define AX_SWRESET_PRTE0x04
+#define AX_SWRESET_PRL 0x08
+#define AX_SWRESET_IPRL0x20
+#define AX_SWRESET_IPPD0x40
+
+#define AX88772_IPG0_DEFAULT 0x15
+#define AX88772_IPG1_DEFAULT 0x0c
+#define AX88772_IPG2_DEFAULT 0x12
+
+/* AX88772 AX88178 Medium Mode Register */
+#define AX_MEDIUM_PF 0x0080
+#define AX_MEDIUM_JFE 0x0040
+#define AX_MEDIUM_TFC 0x0020
+#define AX_MEDIUM_RFC 0x0010
+#define AX_MEDIUM_ENCK 0x0008
+#define AX_MEDIUM_AC 0x0004
+#define AX_MEDIUM_FD 0x0002
+#define AX_MEDIUM_GM 0x0001
+#define AX_MEDIUM_SM 0x1000
+#define AX_MEDIUM_SBP 0x0800
+#define AX_MEDIUM_PS 0x0200
+#define AX_MEDIUM_RE 0x0100
+
+#define AX88178_MEDIUM_DEFAULT \
+ (AX_MEDIUM_PS | AX_MEDIUM_FD | AX_MEDIUM_AC | \
+AX_MEDIUM_RFC | AX_MEDIUM_TFC | AX_MEDIUM_JFE | \
+AX_MEDIUM_RE)
+
+#define AX88772_MEDIUM_DEFAULT \
+ (AX_MEDIUM_FD | AX_MEDIUM_RFC | \
+AX_MEDIUM_TFC | AX_MEDIUM_PS | \
+AX_MEDIUM_AC | AX_MEDIUM_RE)
+
+/* AX88772 AX88178 RX_CTL values */
+#define AX_RX_CTL_SO 0x0080
+#define AX_RX_CTL_AB 0x0008
+
+#define AX_DEFAULT_RX_CTL \
+ (AX_RX_CTL_SO | AX_RX_CTL_AB)
+
+/* GPIO 2 toggles */
+#define AX_GPIO_GPO2EN 0x10/* GPIO2 Output enable */
+#define AX_GPIO_GPO_2 0x20/* GPIO2 Output value */
+#define AX_GPIO_RSE0x80/* Reload serial EEPROM */
+
+/* local defines */
+#define ASIX_BASE_NAME asx
+#define USB_CTRL_SET_TIMEOUT 5000
+#define USB_CTRL_GET_TIMEOUT 5000
+#define USB_BULK_SEND_TIMEOUT 5000
+#define USB_BULK_RECV_TIMEOUT 5000
+
+#define AX_RX_URB_SIZE 2048
+#define PHY_CONNECT_TIMEOUT 5000
+
+/* local vars */
+static int curr_eth_dev; /* index for name of next device detected */
+
+/*
+ * Asix infrastructure commands
+ */
+static int asix_write_cmd(struct ueth_data *dev, u8 cmd, u16 value, u16 index,
+u16 size, void *data)
+{
+ int len;
+
+ debug(asix_write_cmd() cmd=0x%02x value=0x%04x index=0x%04x
+ size=%d\n, cmd, value, index, size);
+
+ len = usb_control_msg(
+ dev-pusb_dev,
+
Re: [U-Boot] [PATCH 1/2 V2] Add USB host ethernet adapter support
Yes, please see my post. Sorry for the delay. I have trouble building the u-boot-usb master branch. Are all boards supposed to build correct in that branch? - Simon On Fri, Feb 11, 2011 at 12:33 PM, Remy Bohmer li...@bohmer.net wrote: 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
[U-Boot] [PATCH] Add A9 CPU complex support
This patch adds code to initialize the A9 dual CPU complex in the Tegra2 SoC. The code is run on the AVP first to set up the A9 and Coresight clocks, then the AVP is halted, the A9 CPU is brought out of reset, and the code executes again on the CPU, but down a slightly different path. Normal POST then proceeds using the A9 CPU. Tom Warren (1): arm: Tegra2: add support for A9 CPU init arch/arm/cpu/armv7/start.S |6 + arch/arm/cpu/armv7/tegra2/Makefile |2 +- arch/arm/cpu/armv7/tegra2/ap20.c | 490 arch/arm/cpu/armv7/tegra2/ap20.h | 105 ++ arch/arm/include/asm/arch-tegra2/clk_rst.h | 27 ++ arch/arm/include/asm/arch-tegra2/pmc.h |8 + arch/arm/include/asm/arch-tegra2/scu.h | 43 +++ arch/arm/include/asm/arch-tegra2/tegra2.h |5 + board/nvidia/common/board.c| 10 + board/nvidia/common/board.h| 29 ++ include/configs/harmony.h |1 + include/configs/seaboard.h |1 + include/configs/tegra2-common.h|2 + 13 files changed, 728 insertions(+), 1 deletions(-) create mode 100644 arch/arm/cpu/armv7/tegra2/ap20.c create mode 100644 arch/arm/cpu/armv7/tegra2/ap20.h create mode 100644 arch/arm/include/asm/arch-tegra2/scu.h create mode 100644 board/nvidia/common/board.h -- 1.7.4.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arm: Tegra2: add support for A9 CPU init
Signed-off-by: Tom Warren twar...@nvidia.com
---
arch/arm/cpu/armv7/start.S |6 +
arch/arm/cpu/armv7/tegra2/Makefile |2 +-
arch/arm/cpu/armv7/tegra2/ap20.c | 490
arch/arm/cpu/armv7/tegra2/ap20.h | 105 ++
arch/arm/include/asm/arch-tegra2/clk_rst.h | 27 ++
arch/arm/include/asm/arch-tegra2/pmc.h |8 +
arch/arm/include/asm/arch-tegra2/scu.h | 43 +++
arch/arm/include/asm/arch-tegra2/tegra2.h |5 +
board/nvidia/common/board.c| 10 +
board/nvidia/common/board.h| 29 ++
include/configs/harmony.h |1 +
include/configs/seaboard.h |1 +
include/configs/tegra2-common.h|2 +
13 files changed, 728 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/cpu/armv7/tegra2/ap20.c
create mode 100644 arch/arm/cpu/armv7/tegra2/ap20.h
create mode 100644 arch/arm/include/asm/arch-tegra2/scu.h
create mode 100644 board/nvidia/common/board.h
diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
index 684f2d2..50a1725 100644
--- a/arch/arm/cpu/armv7/start.S
+++ b/arch/arm/cpu/armv7/start.S
@@ -70,6 +70,12 @@ _end_vect:
_TEXT_BASE:
.word CONFIG_SYS_TEXT_BASE
+#ifdef CONFIG_TEGRA2
+.globl _armboot_start
+_armboot_start:
+.word _start
+#endif
+
/*
* These are defined in the board-specific linker script.
*/
diff --git a/arch/arm/cpu/armv7/tegra2/Makefile
b/arch/arm/cpu/armv7/tegra2/Makefile
index 687c887..f1ea915 100644
--- a/arch/arm/cpu/armv7/tegra2/Makefile
+++ b/arch/arm/cpu/armv7/tegra2/Makefile
@@ -28,7 +28,7 @@ include $(TOPDIR)/config.mk
LIB= $(obj)lib$(SOC).o
SOBJS := lowlevel_init.o
-COBJS := board.o sys_info.o timer.o
+COBJS := ap20.o board.o sys_info.o timer.o
SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS))
diff --git a/arch/arm/cpu/armv7/tegra2/ap20.c b/arch/arm/cpu/armv7/tegra2/ap20.c
new file mode 100644
index 000..89d0d5e
--- /dev/null
+++ b/arch/arm/cpu/armv7/tegra2/ap20.c
@@ -0,0 +1,490 @@
+/*
+* (C) Copyright 2010-2011
+* NVIDIA Corporation www.nvidia.com
+*
+* See file CREDITS for list of people who contributed to this
+* project.
+*
+* This program is free software; you can redistribute it and/or
+* modify it under the terms of the GNU General Public License as
+* published by the Free Software Foundation; either version 2 of
+* the License, or (at your option) any later version.
+*
+* This program is distributed in the hope that it will be useful,
+* but WITHOUT ANY WARRANTY; without even the implied warranty of
+* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+* GNU General Public License for more details.
+*
+* You should have received a copy of the GNU General Public License
+* along with this program; if not, write to the Free Software
+* Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+* MA 02111-1307 USA
+*/
+
+#include ap20.h
+#include asm/io.h
+#include asm/arch/tegra2.h
+#include asm/arch/clk_rst.h
+#include asm/arch/pmc.h
+#include asm/arch/pinmux.h
+#include asm/arch/scu.h
+#include common.h
+
+static void init_pll_x(void)
+{
+ struct clk_rst_ctlr *clkrst = (struct clk_rst_ctlr *)NV_PA_CLK_RST_BASE;
+ u32 reg;
+
+ /* Is PLL-X already running? */
+ reg = readl(clkrst-crc_pllx_base);
+ if (reg PLL_ENABLE)
+ return;
+
+ /* Do PLLX init if it isn't running, but BootROM sets it, so TBD */
+}
+
+static void set_cpu_reset_vector(u32 vector)
+{
+ writel(vector, EXCEP_VECTOR_CPU_RESET_VECTOR);
+}
+
+static void enable_cpu_clock(int enable)
+{
+ struct clk_rst_ctlr *clkrst = (struct clk_rst_ctlr *)NV_PA_CLK_RST_BASE;
+ u32 reg, clk;
+
+ /*
+* NOTE:
+* Regardless of whether the request is to enable or disable the CPU
+* clock, every processor in the CPU complex except the master (CPU 0)
+* will have it's clock stopped because the AVP only talks to the
+* master. The AVP does not know (nor does it need to know) that there
+* are multiple processors in the CPU complex.
+*/
+
+ /* Need to initialize PLLX? */
+ if (enable) {
+ /* Initialize PLL */
+ init_pll_x();
+
+ /* Wait until stable */
+ udelay(NVBOOT_CLOCKS_PLL_STABILIZATION_DELAY);
+
+ reg = CCLK_BURST_POLICY;
+ writel(reg, clkrst-crc_cclk_brst_pol);
+
+ reg = SUPER_CCLK_DIVIDER;
+ writel(reg, clkrst-crc_super_cclk_div);
+ }
+
+ /* Fetch the register containing the main CPU complex clock enable */
+ reg = readl(clkrst-crc_clk_out_enb_l);
+
+ /*
+* Read the register containing the individual CPU clock enables and
+* always stop the clock to CPU 1.
+*/
+ clk = readl(clkrst-crc_clk_cpu_cmplx);
+ clk |= CPU1_CLK_STP;
+
[U-Boot] (no subject)
Hi Mike, Thanks for the feedback, and for the cool unification. Here is the updated patch that implements your comments and is based on the head of the blackfin.git sf branch. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] SPI: Add struct spi_flash.sector_size parameter
This patch adds a new member to struct spi_flash (u16 sector_size)
and updates the spi flash drivers to start populating it.
This parameter can be used by spi flash commands that need to round
up units of operation to the flash's sector_size.
---
drivers/mtd/spi/atmel.c|1 +
drivers/mtd/spi/macronix.c |1 +
drivers/mtd/spi/spansion.c |4 ++--
drivers/mtd/spi/sst.c |3 ++-
drivers/mtd/spi/stmicro.c |4 ++--
drivers/mtd/spi/winbond.c |5 +++--
include/spi_flash.h|2 ++
7 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/drivers/mtd/spi/atmel.c b/drivers/mtd/spi/atmel.c
index a9910b1..180a52b 100644
--- a/drivers/mtd/spi/atmel.c
+++ b/drivers/mtd/spi/atmel.c
@@ -498,6 +498,7 @@ struct spi_flash *spi_flash_probe_atmel(struct spi_slave
*spi, u8 *idcode)
asf-flash.size = page_size * params-pages_per_block
* params-blocks_per_sector
* params-nr_sectors;
+ asf-flash.sector_size = page_size;
printf(SF: Detected %s with page size %u, total ,
params-name, page_size);
diff --git a/drivers/mtd/spi/macronix.c b/drivers/mtd/spi/macronix.c
index 4155d4d..4a8e17f 100644
--- a/drivers/mtd/spi/macronix.c
+++ b/drivers/mtd/spi/macronix.c
@@ -217,6 +217,7 @@ struct spi_flash *spi_flash_probe_macronix(struct spi_slave
*spi, u8 *idcode)
mcx-flash.read = spi_flash_cmd_read_fast;
mcx-flash.size = params-page_size * params-pages_per_sector
* params-sectors_per_block * params-nr_blocks;
+ mcx-flash.sector_size = mcx-flash.size/params-nr_blocks;
printf(SF: Detected %s with page size %u, total ,
params-name, params-page_size);
diff --git a/drivers/mtd/spi/spansion.c b/drivers/mtd/spi/spansion.c
index d54a5fa..c88457b 100644
--- a/drivers/mtd/spi/spansion.c
+++ b/drivers/mtd/spi/spansion.c
@@ -199,8 +199,7 @@ static int spansion_write(struct spi_flash *flash,
int spansion_erase(struct spi_flash *flash, u32 offset, size_t len)
{
struct spansion_spi_flash *spsn = to_spansion_spi_flash(flash);
- return spi_flash_cmd_erase(flash, CMD_S25FLXX_SE,
- spsn-params-page_size * spsn-params-pages_per_sector,
+ return spi_flash_cmd_erase(flash, CMD_S25FLXX_SE, flash-sector_size,
offset, len);
}
@@ -242,6 +241,7 @@ struct spi_flash *spi_flash_probe_spansion(struct spi_slave
*spi, u8 *idcode)
spsn-flash.read = spi_flash_cmd_read_fast;
spsn-flash.size = params-page_size * params-pages_per_sector
* params-nr_sectors;
+ spsn-flash.sector_size = spsn-flash.size/params-nr_sectors;
printf(SF: Detected %s with page size %u, total ,
params-name, params-page_size);
diff --git a/drivers/mtd/spi/sst.c b/drivers/mtd/spi/sst.c
index 792d04d..15de12b 100644
--- a/drivers/mtd/spi/sst.c
+++ b/drivers/mtd/spi/sst.c
@@ -201,7 +201,7 @@ sst_write(struct spi_flash *flash, u32 offset, size_t len,
const void *buf)
int sst_erase(struct spi_flash *flash, u32 offset, size_t len)
{
- return spi_flash_cmd_erase(flash, CMD_SST_SE, SST_SECTOR_SIZE,
+ return spi_flash_cmd_erase(flash, CMD_SST_SE, flash-sector_size,
offset, len);
}
@@ -257,6 +257,7 @@ spi_flash_probe_sst(struct spi_slave *spi, u8 *idcode)
stm-flash.write = sst_write;
stm-flash.erase = sst_erase;
stm-flash.size = SST_SECTOR_SIZE * params-nr_sectors;
+ stm-flash.sector_size = SST_SECTOR_SIZE;
printf(SF: Detected %s with page size %u, total ,
params-name, SST_SECTOR_SIZE);
diff --git a/drivers/mtd/spi/stmicro.c b/drivers/mtd/spi/stmicro.c
index 7ef690d..80d838e 100644
--- a/drivers/mtd/spi/stmicro.c
+++ b/drivers/mtd/spi/stmicro.c
@@ -200,8 +200,7 @@ static int stmicro_write(struct spi_flash *flash,
int stmicro_erase(struct spi_flash *flash, u32 offset, size_t len)
{
struct stmicro_spi_flash *stm = to_stmicro_spi_flash(flash);
- return spi_flash_cmd_erase(flash, CMD_M25PXX_SE,
- stm-params-page_size * stm-params-pages_per_sector,
+ return spi_flash_cmd_erase(flash, CMD_M25PXX_SE, flash-sector_size,
offset, len);
}
@@ -251,6 +250,7 @@ struct spi_flash *spi_flash_probe_stmicro(struct spi_slave
*spi, u8 * idcode)
stm-flash.read = spi_flash_cmd_read_fast;
stm-flash.size = params-page_size * params-pages_per_sector
* params-nr_sectors;
+ stm-flash.sector_size = stm-flash.size/params-nr_sectors;
printf(SF: Detected %s with page size %u, total ,
params-name, params-page_size);
diff --git a/drivers/mtd/spi/winbond.c b/drivers/mtd/spi/winbond.c
index e88802f..ec6fb79 100644
--- a/drivers/mtd/spi/winbond.c
+++ b/drivers/mtd/spi/winbond.c
@@ -173,8 +173,7 @@ out:
int winbond_erase(struct spi_flash *flash, u32 offset, size_t len)
{
struct winbond_spi_flash *stm =
[U-Boot] [PATCH 2/2] cmd_sf: Add handler for +len arg for erase command.
This patch adds [+]len handler for the erase command that will
automatically round up the requested erase length to the flash's
sector_size.
---
common/cmd_sf.c | 53 +
1 files changed, 49 insertions(+), 4 deletions(-)
diff --git a/common/cmd_sf.c b/common/cmd_sf.c
index 6e7be81..bbd4842 100644
--- a/common/cmd_sf.c
+++ b/common/cmd_sf.c
@@ -19,6 +19,48 @@
static struct spi_flash *flash;
+
+/*
+ * This function computes the length argument for the erase command.
+ * The length on which the command is to operate can be given in two forms:
+ * 1. cmd offset len - operate on 'offset', 'len')
+ * 2. cmd offset +len - operate on 'offset', 'round_up(len)')
+ * If the second form is used and the length doesn't fall on the
+ * sector boundary, than it will be adjusted to the next sector boundary.
+ * If it isn't in the flash, the function will fail (return -1).
+ * Input:
+ *arg: length specification (i.e. both command arguments)
+ * Output:
+ *len: computed length for operation
+ * Return:
+ *1: success
+ * -1: failure (bad format, bad address).
+*/
+static int sf_parse_len_arg(char *arg, ulong *len)
+{
+ char *ep;
+ char round_up_len; /* indicates if the +length form used */
+ ulong len_arg;
+
+
+ round_up_len = 0;
+ if (*arg == '+'){
+ round_up_len = 1;
+ ++arg;
+ }
+
+ len_arg = simple_strtoul(arg, ep, 16);
+ if (ep == arg || *ep != '\0')
+ return -1;
+
+ if (round_up_len flash-sector_size 0)
+ *len = DIV_ROUND_UP(len_arg, flash-sector_size);
+ else
+ *len = len_arg;
+
+ return 1;
+}
+
static int do_spi_flash_probe(int argc, char * const argv[])
{
unsigned int bus = 0;
@@ -135,9 +177,11 @@ static int do_spi_flash_erase(int argc, char * const
argv[])
offset = simple_strtoul(argv[1], endp, 16);
if (*argv[1] == 0 || *endp != 0)
goto usage;
- len = simple_strtoul(argv[2], endp, 16);
- if (*argv[2] == 0 || *endp != 0)
+
+ ret = sf_parse_len_arg(argv[2], len);
+ if (ret != 1) {
goto usage;
+ }
ret = spi_flash_erase(flash, offset, len);
if (ret) {
@@ -148,7 +192,7 @@ static int do_spi_flash_erase(int argc, char * const argv[])
return 0;
usage:
- puts(Usage: sf erase offset len\n);
+ puts(Usage: sf erase offset [+]len\n);
return 1;
}
@@ -189,5 +233,6 @@ U_BOOT_CMD(
`offset' to memory at `addr'\n
sf write addr offset len - write `len' bytes from memory\n
at `addr' to flash at `offset'\n
- sf erase offset len- erase `len' bytes from `offset'
+ sf erase offset [+]len - erase `len' bytes from `offset'\n
+`+len' round up `len' to block size
);
--
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/2 V2] Add USB host ethernet adapter support
Hi, 2011/2/16 Simon Glass s...@chromium.org: Yes, please see my post. Sorry for the delay. I have trouble building the u-boot-usb master branch. Are all boards supposed to build correct in that branch? - Simon The master of u-boot-usb is basically mainstream u-boot. And as with mainstream u-boot, many ARM boards are broken... 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] SPI: Add struct spi_flash.sector_size parameter
Dear Richard Retanubun, In message 1297888074-8344-2-git-send-email-richardretanu...@ruggedcom.com you wrote: This patch adds a new member to struct spi_flash (u16 sector_size) and updates the spi flash drivers to start populating it. This parameter can be used by spi flash commands that need to round up units of operation to the flash's sector_size. --- drivers/mtd/spi/atmel.c|1 + drivers/mtd/spi/macronix.c |1 + drivers/mtd/spi/spansion.c |4 ++-- drivers/mtd/spi/sst.c |3 ++- drivers/mtd/spi/stmicro.c |4 ++-- drivers/mtd/spi/winbond.c |5 +++-- include/spi_flash.h|2 ++ 7 files changed, 13 insertions(+), 7 deletions(-) Rejected - Signed-off-by: line missing. 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 God made the integers; all else is the work of Man. - Kronecker ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] cmd_sf: Add handler for +len arg for erase command.
Dear Richard Retanubun,
In message 1297888074-8344-3-git-send-email-richardretanu...@ruggedcom.com
you wrote:
This patch adds [+]len handler for the erase command that will
automatically round up the requested erase length to the flash's
sector_size.
---
common/cmd_sf.c | 53 +
1 files changed, 49 insertions(+), 4 deletions(-)
Please run your patches through checkpatch - this helps avoiding the
frustration of seeing rejects due to simple issues like these:
ERROR: Missing Signed-off-by: line(s)
+ if (*arg == '+'){
ERROR: space required before the open brace '{'
+ if (ret != 1) {
goto usage;
+ }
WARNING: braces {} are not necessary for single statement blocks
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
All these theories, diverse as they are, have two things in common:
they explain the observed facts, and they are completeley and utterly
wrong. - Terry Pratchett, _The Light Fantastic_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM: Update mach-types
From: Sandeep Paulraj s-paul...@ti.com This commit updates the mach-types based on the latest in linus's head Signed-off-by: Sandeep Paulraj s-paul...@ti.com --- arch/arm/include/asm/mach-types.h | 1291 - 1 files changed, 1276 insertions(+), 15 deletions(-) diff --git a/arch/arm/include/asm/mach-types.h b/arch/arm/include/asm/mach-types.h index d95e6d6..a1fd03a 100644 --- a/arch/arm/include/asm/mach-types.h +++ b/arch/arm/include/asm/mach-types.h @@ -2236,7 +2236,7 @@ extern unsigned int __machine_arch_type; #define MACH_TYPE_VS_V210 2252 #define MACH_TYPE_VS_V212 2253 #define MACH_TYPE_HMT 2254 -#define MACH_TYPE_SUEN32255 +#define MACH_TYPE_KM_KIRKWOOD 2255 #define MACH_TYPE_VESPER 2256 #define MACH_TYPE_STR9 2257 #define MACH_TYPE_OMAP3_WL_FF 2258 @@ -2983,7 +2983,7 @@ extern unsigned int __machine_arch_type; #define MACH_TYPE_EA20 3002 #define MACH_TYPE_AWM2 3003 #define MACH_TYPE_TI8148EVM3004 -#define MACH_TYPE_TEGRA_SEABOARD 3005 +#define MACH_TYPE_SEABOARD 3005 #define MACH_TYPE_LINKSTATION_CHLV23006 #define MACH_TYPE_TERA_PRO2_RACK 3007 #define MACH_TYPE_RUBYS3008 @@ -3186,7 +3186,7 @@ extern unsigned int __machine_arch_type; #define MACH_TYPE_ICS_IF_VOIP 3206 #define MACH_TYPE_WLF_CRAGG_6410 3207 #define MACH_TYPE_PUNICA 3208 -#define MACH_TYPE_SBC_NT2503209 +#define MACH_TYPE_TRIMSLICE3209 #define MACH_TYPE_MX27_WMULTRA 3210 #define MACH_TYPE_MACKEREL 3211 #define MACH_TYPE_FA9X27 3213 @@ -3215,6 +3215,103 @@ extern unsigned int __machine_arch_type; #define MACH_TYPE_PCM048 3236 #define MACH_TYPE_DDS 3237 #define MACH_TYPE_CHALTEN_XA1 3238 +#define MACH_TYPE_TS48XX 3239 +#define MACH_TYPE_TONGA2_TFTTIMER 3240 +#define MACH_TYPE_WHISTLER 3241 +#define MACH_TYPE_ASL_PHOENIX 3242 +#define MACH_TYPE_AT91SAM9263OTLITE3243 +#define MACH_TYPE_DDPLUG 3244 +#define MACH_TYPE_D2PLUG 3245 +#define MACH_TYPE_KZM9D3246 +#define MACH_TYPE_VERDI_LTE3247 +#define MACH_TYPE_NANOZOOM 3248 +#define MACH_TYPE_DM3730_SOM_LV3249 +#define MACH_TYPE_DM3730_TORPEDO 3250 +#define MACH_TYPE_ANCHOVY 3251 +#define MACH_TYPE_RE2REV20 3253 +#define MACH_TYPE_RE2REV21 3254 +#define MACH_TYPE_CNS21XX 3255 +#define MACH_TYPE_RIDER3257 +#define MACH_TYPE_NSK330 3258 +#define MACH_TYPE_CNS2133EVB 3259 +#define MACH_TYPE_Z3_816X_MOD 3260 +#define MACH_TYPE_Z3_814X_MOD 3261 +#define MACH_TYPE_BEECT3262 +#define MACH_TYPE_DMA_THUNDERBUG 3263 +#define MACH_TYPE_OMN_AT91SAM9G20 3264 +#define MACH_TYPE_MX25_E2S_UC 3265 +#define MACH_TYPE_MIONE3266 +#define MACH_TYPE_TOP9000_TCU 3267 +#define MACH_TYPE_TOP9000_BSL 3268 +#define MACH_TYPE_KINGDOM 3269 +#define MACH_TYPE_ARMADILLO460 3270 +#define MACH_TYPE_LQ2 3271 +#define MACH_TYPE_SWEDA_TMS2 3272 +#define MACH_TYPE_MX53_LOCO3273 +#define MACH_TYPE_ACER_A8 3275 +#define MACH_TYPE_ACER_GAUGUIN 3276 +#define MACH_TYPE_GUPPY3277 +#define MACH_TYPE_MX61_ARD 3278 +#define MACH_TYPE_TX53 3279 +#define MACH_TYPE_OMAPL138_CASE_A3 3280 +#define MACH_TYPE_UEMD 3281 +#define MACH_TYPE_CCWMX51MUT 3282 +#define MACH_TYPE_ROCKHOPPER 3283 +#define MACH_TYPE_NOOKCOLOR3284 +#define MACH_TYPE_HKDKC100 3285 +#define MACH_TYPE_TS42XX 3286 +#define MACH_TYPE_AEBL 3287 +#define MACH_TYPE_WARIO3288 +#define MACH_TYPE_GFS_SPM 3289 +#define MACH_TYPE_CM_T3730 3290 +#define MACH_TYPE_ISC3 3291 +#define MACH_TYPE_RASCAL 3292 +#define MACH_TYPE_HREFV60 3293 +#define MACH_TYPE_TPT_2_0 3294 +#define MACH_TYPE_PYRAMID_TD 3295 +#define MACH_TYPE_SPLENDOR 3296 +#define MACH_TYPE_GUF_PLANET 3297 +#define MACH_TYPE_MSM8X60_QT 3298 +#define MACH_TYPE_HTC_HD_MINI 3299 +#define MACH_TYPE_ATHENE 3300 +#define MACH_TYPE_DEEP_R_EK_1 3301 +#define MACH_TYPE_VIVOW_CT 3302 +#define MACH_TYPE_NERY_10003303 +#define MACH_TYPE_RFL109145_SSRV 3304 +#define MACH_TYPE_NMH 3305 +#define MACH_TYPE_WN802T 3306 +#define MACH_TYPE_DRAGONET 3307 +#define MACH_TYPE_GENEVA_B 3308 +#define
[U-Boot] [PATCH 1/2] SPI: Add struct spi_flash.sector_size parameter
This patch adds a new member to struct spi_flash (u16 sector_size)
and updates the spi flash drivers to start populating it.
This parameter can be used by spi flash commands that need to round
up units of operation to the flash's sector_size.
Signed-off-by: Richard Retanubun richardretanu...@ruggedcom.com
---
v2: scrubbed via checkpatch, thanks WD!
drivers/mtd/spi/atmel.c|1 +
drivers/mtd/spi/macronix.c |1 +
drivers/mtd/spi/spansion.c |4 ++--
drivers/mtd/spi/sst.c |3 ++-
drivers/mtd/spi/stmicro.c |4 ++--
drivers/mtd/spi/winbond.c |5 +++--
include/spi_flash.h|2 ++
7 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/drivers/mtd/spi/atmel.c b/drivers/mtd/spi/atmel.c
index a9910b1..180a52b 100644
--- a/drivers/mtd/spi/atmel.c
+++ b/drivers/mtd/spi/atmel.c
@@ -498,6 +498,7 @@ struct spi_flash *spi_flash_probe_atmel(struct spi_slave
*spi, u8 *idcode)
asf-flash.size = page_size * params-pages_per_block
* params-blocks_per_sector
* params-nr_sectors;
+ asf-flash.sector_size = page_size;
printf(SF: Detected %s with page size %u, total ,
params-name, page_size);
diff --git a/drivers/mtd/spi/macronix.c b/drivers/mtd/spi/macronix.c
index 4155d4d..4a8e17f 100644
--- a/drivers/mtd/spi/macronix.c
+++ b/drivers/mtd/spi/macronix.c
@@ -217,6 +217,7 @@ struct spi_flash *spi_flash_probe_macronix(struct spi_slave
*spi, u8 *idcode)
mcx-flash.read = spi_flash_cmd_read_fast;
mcx-flash.size = params-page_size * params-pages_per_sector
* params-sectors_per_block * params-nr_blocks;
+ mcx-flash.sector_size = mcx-flash.size/params-nr_blocks;
printf(SF: Detected %s with page size %u, total ,
params-name, params-page_size);
diff --git a/drivers/mtd/spi/spansion.c b/drivers/mtd/spi/spansion.c
index d54a5fa..c88457b 100644
--- a/drivers/mtd/spi/spansion.c
+++ b/drivers/mtd/spi/spansion.c
@@ -199,8 +199,7 @@ static int spansion_write(struct spi_flash *flash,
int spansion_erase(struct spi_flash *flash, u32 offset, size_t len)
{
struct spansion_spi_flash *spsn = to_spansion_spi_flash(flash);
- return spi_flash_cmd_erase(flash, CMD_S25FLXX_SE,
- spsn-params-page_size * spsn-params-pages_per_sector,
+ return spi_flash_cmd_erase(flash, CMD_S25FLXX_SE, flash-sector_size,
offset, len);
}
@@ -242,6 +241,7 @@ struct spi_flash *spi_flash_probe_spansion(struct spi_slave
*spi, u8 *idcode)
spsn-flash.read = spi_flash_cmd_read_fast;
spsn-flash.size = params-page_size * params-pages_per_sector
* params-nr_sectors;
+ spsn-flash.sector_size = spsn-flash.size/params-nr_sectors;
printf(SF: Detected %s with page size %u, total ,
params-name, params-page_size);
diff --git a/drivers/mtd/spi/sst.c b/drivers/mtd/spi/sst.c
index 792d04d..15de12b 100644
--- a/drivers/mtd/spi/sst.c
+++ b/drivers/mtd/spi/sst.c
@@ -201,7 +201,7 @@ sst_write(struct spi_flash *flash, u32 offset, size_t len,
const void *buf)
int sst_erase(struct spi_flash *flash, u32 offset, size_t len)
{
- return spi_flash_cmd_erase(flash, CMD_SST_SE, SST_SECTOR_SIZE,
+ return spi_flash_cmd_erase(flash, CMD_SST_SE, flash-sector_size,
offset, len);
}
@@ -257,6 +257,7 @@ spi_flash_probe_sst(struct spi_slave *spi, u8 *idcode)
stm-flash.write = sst_write;
stm-flash.erase = sst_erase;
stm-flash.size = SST_SECTOR_SIZE * params-nr_sectors;
+ stm-flash.sector_size = SST_SECTOR_SIZE;
printf(SF: Detected %s with page size %u, total ,
params-name, SST_SECTOR_SIZE);
diff --git a/drivers/mtd/spi/stmicro.c b/drivers/mtd/spi/stmicro.c
index 7ef690d..80d838e 100644
--- a/drivers/mtd/spi/stmicro.c
+++ b/drivers/mtd/spi/stmicro.c
@@ -200,8 +200,7 @@ static int stmicro_write(struct spi_flash *flash,
int stmicro_erase(struct spi_flash *flash, u32 offset, size_t len)
{
struct stmicro_spi_flash *stm = to_stmicro_spi_flash(flash);
- return spi_flash_cmd_erase(flash, CMD_M25PXX_SE,
- stm-params-page_size * stm-params-pages_per_sector,
+ return spi_flash_cmd_erase(flash, CMD_M25PXX_SE, flash-sector_size,
offset, len);
}
@@ -251,6 +250,7 @@ struct spi_flash *spi_flash_probe_stmicro(struct spi_slave
*spi, u8 * idcode)
stm-flash.read = spi_flash_cmd_read_fast;
stm-flash.size = params-page_size * params-pages_per_sector
* params-nr_sectors;
+ stm-flash.sector_size = stm-flash.size/params-nr_sectors;
printf(SF: Detected %s with page size %u, total ,
params-name, params-page_size);
diff --git a/drivers/mtd/spi/winbond.c b/drivers/mtd/spi/winbond.c
index e88802f..ec6fb79 100644
--- a/drivers/mtd/spi/winbond.c
+++ b/drivers/mtd/spi/winbond.c
@@ -173,8 +173,7 @@ out:
int
[U-Boot] [PATCH 2/2] cmd_sf: Add handler for +len arg for erase command.
This patch adds [+]len handler for the erase command that will
automatically round up the requested erase length to the flash's
sector_size.
Signed-off-by: Richard Retanubun richardretanu...@ruggedcom.com
---
v2: scrubbed via checkpatch, thanks WD!
common/cmd_sf.c | 52
1 files changed, 48 insertions(+), 4 deletions(-)
diff --git a/common/cmd_sf.c b/common/cmd_sf.c
index 6e7be81..17a4dd8 100644
--- a/common/cmd_sf.c
+++ b/common/cmd_sf.c
@@ -19,6 +19,48 @@
static struct spi_flash *flash;
+
+/*
+ * This function computes the length argument for the erase command.
+ * The length on which the command is to operate can be given in two forms:
+ * 1. cmd offset len - operate on 'offset', 'len')
+ * 2. cmd offset +len - operate on 'offset', 'round_up(len)')
+ * If the second form is used and the length doesn't fall on the
+ * sector boundary, than it will be adjusted to the next sector boundary.
+ * If it isn't in the flash, the function will fail (return -1).
+ * Input:
+ *arg: length specification (i.e. both command arguments)
+ * Output:
+ *len: computed length for operation
+ * Return:
+ *1: success
+ * -1: failure (bad format, bad address).
+*/
+static int sf_parse_len_arg(char *arg, ulong *len)
+{
+ char *ep;
+ char round_up_len; /* indicates if the +length form used */
+ ulong len_arg;
+
+
+ round_up_len = 0;
+ if (*arg == '+') {
+ round_up_len = 1;
+ ++arg;
+ }
+
+ len_arg = simple_strtoul(arg, ep, 16);
+ if (ep == arg || *ep != '\0')
+ return -1;
+
+ if (round_up_len flash-sector_size 0)
+ *len = DIV_ROUND_UP(len_arg, flash-sector_size);
+ else
+ *len = len_arg;
+
+ return 1;
+}
+
static int do_spi_flash_probe(int argc, char * const argv[])
{
unsigned int bus = 0;
@@ -135,8 +177,9 @@ static int do_spi_flash_erase(int argc, char * const argv[])
offset = simple_strtoul(argv[1], endp, 16);
if (*argv[1] == 0 || *endp != 0)
goto usage;
- len = simple_strtoul(argv[2], endp, 16);
- if (*argv[2] == 0 || *endp != 0)
+
+ ret = sf_parse_len_arg(argv[2], len);
+ if (ret != 1)
goto usage;
ret = spi_flash_erase(flash, offset, len);
@@ -148,7 +191,7 @@ static int do_spi_flash_erase(int argc, char * const argv[])
return 0;
usage:
- puts(Usage: sf erase offset len\n);
+ puts(Usage: sf erase offset [+]len\n);
return 1;
}
@@ -189,5 +232,6 @@ U_BOOT_CMD(
`offset' to memory at `addr'\n
sf write addr offset len - write `len' bytes from memory\n
at `addr' to flash at `offset'\n
- sf erase offset len- erase `len' bytes from `offset'
+ sf erase offset [+]len - erase `len' bytes from `offset'\n
+`+len' round up `len' to block size
);
--
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 2/2] cmd_sf: Add handler for +len arg for erase command.
On Wed, 16 Feb 2011 15:27:54 -0500 Richard Retanubun richardretanu...@ruggedcom.com wrote: This patch adds [+]len handler for the erase command that will automatically round up the requested erase length to the flash's sector_size. --- common/cmd_sf.c | 53 + 1 files changed, 49 insertions(+), 4 deletions(-) diff --git a/common/cmd_sf.c b/common/cmd_sf.c index 6e7be81..bbd4842 100644 --- a/common/cmd_sf.c +++ b/common/cmd_sf.c @@ -19,6 +19,48 @@ static struct spi_flash *flash; + +/* + * This function computes the length argument for the erase command. + * The length on which the command is to operate can be given in two forms: + * 1. cmd offset len - operate on 'offset', 'len') + * 2. cmd offset +len - operate on 'offset', 'round_up(len)') + * If the second form is used and the length doesn't fall on the + * sector boundary, than it will be adjusted to the next sector boundary. + * If it isn't in the flash, the function will fail (return -1). On NOR, + is used to indicate that the second argument is a length, as opposed to an ending address. Rounding seems like a side effect of length mode. On NAND we unconditionally round up erase lengths, as we don't support ending-address mode (looks like SPI doesn't either). -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] IXP42x patch series version 3 - patch summaries
Am 02/14/2011 01:00 PM, schrieb Albert ARIBAUD: Le 14/02/2011 00:38, Michael Schwingen a écrit : Am 02/13/2011 11:03 PM, schrieb Wolfgang Denk: Dear Graeme Russ, In messageAANLkTikxv+ATsYAP5ismLo5pj=TrFV_oQNk=8qvh1...@mail.gmail.com you wrote: For multi-patch series, you only need to put the revision history in the [00/nn] file - No need to individually annotate each and every patch This is *wrong*. See the Note at bullet 2 at http://www.denx.de/wiki/view/U-Boot/Patches#Sending_updated_patch_versions (I plead guilty, then. I, too, did put patchset history only in the summary post, and never commented others who did it too) You are probably not guilty - that requirement only appeared in the Wiki page on 11 Jan 2011, in an edit by Wolfgang Denk: http://www.denx.de/wiki/rdiff/U-Boot/Patches?rev2=1.28rev1=1.29 cu Michael ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [v5 patch 1/6] SMDK6400: Fix CONFIG_SYS_INIT_SP_ADDR undefined
On 23 January 2011 05:06, seedshope bocui...@gmail.com wrote: Fix CONFIG_SYS_INIT_SP_ADDR undefined issue. Signed-off-by: Zhong Hongbo bocui...@gmail.com applied to u-boot-samsung Thanks Minkyu Kang -- from. prom. www.promsoft.net ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [v5 patch 2/6] SMDK6400: Fix some label undefined in build error
On 23 January 2011 05:06, seedshope bocui...@gmail.com wrote: Modify Makefile for cpu_init.c and Start.s use some label,this defined u-boot.lds of arch/arm/cpu/arm1176. But SMDK6400 use the link script board/samsung/smdk6400/u-boot-nand.lds. So add some label form u-boot.lds to u-boot-nand.lds Signed-off-by: Zhong Hongbo bocui...@gmail.com applied to u-boot-samsung Thanks Minkyu Kang -- from. prom. www.promsoft.net ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [v5 patch 3/6] SMDK6400: Fix the mutiple link error
On 23 January 2011 05:06, seedshope bocui...@gmail.com wrote: The first, the cpu_init.o have already been link for cmd_link_o_target atfer compile, But, The link script re-link the point file. So the link machine will generate multiple definition error information. The second, Since the first 4kB of nand boot featue code move to nand_spl, So It is not necessary to force the cpu_init.o in non-nand boot. Signed-off-by: Zhong Hongbo bocui...@gmail.com applied to u-boot-samsung Thanks Minkyu Kang -- from. prom. www.promsoft.net ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [v5 patch 4/6] SMDK6400: Add some labels to u-boot.lds to support nand_spl
On 23 January 2011 05:06, seedshope bocui...@gmail.com wrote: In the nand_spl feature of SMDK6400. Add some relocation symbols to nand_spl/board/samsung/smdk6400/u-boot.lds to fix the compile error. Signed-off-by: Zhong Hongbo bocui...@gmail.com applied to u-boot-samsung Thanks Minkyu Kang -- from. prom. www.promsoft.net ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [v5 patch 5/6] SMDK6400: Disable LED function in start.s on the nand booting
On 23 January 2011 05:06, seedshope bocui...@gmail.com wrote: Since nand boot have some limit for the first 4KB, We only disable the LED function to reduce the code space. At the same time, Fix the compile error for LED function undefined in the compile time of nand_spl. Signed-off-by: Zhong Hongbo bocui...@gmail.com applied to u-boot-samsung Thanks Minkyu Kang -- from. prom. www.promsoft.net ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [v5 patch 6/6] SMDK6400: Fixup dram_init for relocation support
On 23 January 2011 05:06, seedshope bocui...@gmail.com wrote: Signed-off-by: Zhong Hongbo bocui...@gmail.com diff --git a/board/samsung/smdk6400/smdk6400.c b/board/samsung/smdk6400/smdk6400.c applied to u-boot-samsung Thanks Minkyu Kang -- from. prom. www.promsoft.net ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] at91 spi bus speed
On Wednesday, February 16, 2011 03:26:00 wouter moors wrote: please dont top post But I was wondering most why the bus speed seems to be limited to ~12MHz. Is that a limitation of the at91sam9g20 or more likely a problem with the board design? i was merely covering a question on common code. ive never used u-boot on an arm part let alone the one you quote, so i dont have a clue in that regard. sorry. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] U-boot is not working in Beagle xM board.
Hai, I cant boot the board in the Beable xM board. The board is having processor ARM cortex A8. Please see the below error log. Texas Instruments X-Loader 1.4.4ss (Aug 19 2010 - 02:49:27) Beagle xM Rev A Reading boot sector u-boot.bin not found or blank nand contents - attempting serial boot . . . ## Ready for binary (kermit) download to 0x80008000 at 115200 bps... I copied the u-boot.bin file into the micro SD card as given in their order. Please clarify in this regard. Regards, Chinnathambi M ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Introduce a new linker flag LDFLAGS_FINAL
On Tuesday, February 15, 2011 19:51:00 Scott Wood wrote: On Tue, 15 Feb 2011 04:02:44 -0500 Mike Frysinger wrote: This included anything that cpu/board code added to LDFLAGS -- some architectures added --gc-sections, x86 added --cref, etc. Since the above flags are added to LDFLAGS, rather than replacing them, these flags got used in the final link. Commit 8aba9dc introduces LDFLAGS_u-boot, so that LDFLAGS is no longer the source for the flags for the final link. It generates LDFLAGS_u-boot using PLATFORM_LDFLAGS, not LDFLAGS. It converts most of the board/cpu updates to LDFLAGS into LDFLAGS_u-boot, but it missed --cref. err, i dont think this is correct. LDFLAGS is no longer the *only* source for the final link. if you look at the actual target, you'll see it using $(LDFLAGS) $(LDFLAGS_$(@F)). Ah. So why is PLATFORM_LDFLAGS added into both LDFLAGS and LDFLAGS_u-boot? :-P i'm not saying PLATFORM_LDFLAGS makes sense. it certainly seems like we've outgrown the PLATFORM_XXX flags and could be cleaned up. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] spi subystem maintainer?
On Tuesday, February 15, 2011 18:10:47 Kumar Gala wrote:
On Feb 15, 2011, at 2:36 AM, Mike Frysinger wrote:
On Thursday, February 03, 2011 05:36:38 Kumar Gala wrote:
On Feb 2, 2011, at 3:30 AM, Reinhard Meyer wrote:
Dear Stefano Babic:
On 02/02/2011 08:23 AM, Kumar Gala wrote:
Wanted to see if anyone had input on how to deal with the SPI
controller on some of our newer parts. It expects command data
xfer's to happen together. However our current code does not call
spi_xfer() that way.
Which is your concrete case ? spi_xfer is responsible to setup the
controller and to start the transfer, and everything could be done
inside this function. What do you mean exactly with command and data ?
I think he refers to the common problem that many SPI devices
require CS to stay low during both phases of issuing the
read/write command and transfering the actual data.
Current u-boot code calls spi_xfer() two times.
Hardware controlled CS often go high between both calls, which
requires you to (at least) use GPIO controlled CS, or, even worse,
use bitbang SPI (in cases where the SPI pin assignment is in groups,
not individually).
That's correct, and with the newer FSL controller's we dont have direct
control over the CS. I'm thinking we need to have the command and
response dealt with in a single call to spi_xfer instead of what we seem
to do all over the place today:
ret = spi_xfer(spi, 8, cmd, NULL, flags);
if (ret) {
debug(SF: Failed to send command %02x: %d\n, cmd, ret);
return ret;
}
if (len) {
ret = spi_xfer(spi, len * 8, NULL, response,
SPI_XFER_END); if (ret)
debug(SF: Failed to read response (%zu bytes):
%d\n, len, ret);
}
Needs to turn into something like:
ret = spi_xfer(spi, 8 + len * 8, cmd, response, flags |
SPI_XFER_END)
this should be easier in my sf branch as i unified a bunch of the
functions. but while this will probably work for the main commands, how
is this supposed to work for the status polling ? that function is
fundamentally based around setting up a transfer/command and then
continuously shifting out a single result and checking it before
shifting out another. for your controller, the only way to make it work
is to do the full transaction every time.
Probably have to do a transaction every time.
looking at the Linux driver, it seems to do just that. i guess if Linux is
getting by with a stricter API, then there shouldnt be a problem for U-Boot
either. i dont suppose anyone knows of devices that are problematic in Linux
or would be broken in U-Boot by this API change in general ?
this assumes of course that the SPI API as used in Linux works for you ?
Do you have a tree for these changes? Do you expect them to be in place
for release after v2011.03
the sf branch of my blackfin tree. if no one gives me any feedback (i posted
the patches on the list a while ago), i guess i'll see about merging post the
next release.
-mike
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Introduce a new linker flag LDFLAGS_FINAL
On Wednesday, February 16, 2011 13:58:07 Wolfgang Denk wrote:
Haiying Wang wrote:
We have some 524 PowerPC configurations in boards.cfg, and the compare
must be done for _all_ off these, i. e. there are 2 x 524 pairs of
files to be compared. Did you really do this?
it is ok to apply this patch, if you are ok with the name _FINAL?
Sorry, I did not get the 2x254 pairs of System.map and u-boot.map.
Running MAKEALL powerpc only left the last pair. Could you please show
me how I can keep the former 523 pairs?
I usually do this on the fly using shell scripting capabilities, i.e.
something like this (copying some shell functions from MAKEALL):
---
boards_by_field()
{
awk \
-v field=$1 \
-v select=$2 \
'($1 !~ /^#/ $field == select) { print $1 }' \
boards.cfg
}
boards_by_arch() { boards_by_field 2 $@ ; }
for board in $(boards_by_arch powerpc) ; do
./MAKEALL $board
cp System.map System.map.${board}.unpatched
cp u-boot.map u-boot.map.${board}.unpatched
done
...apply patch...
for board in $(boards_by_arch powerpc) ; do
./MAKEALL $board
cmp System.map.${board}.unpatched System.map || diff -u
System.map.${board}.unpatched System.map System.map.${board}.diff cmp
u-boot.map.${board}.unpatched u-boot.map || diff -u
u-boot.map.${board}.unpatched u-boot.map u-boot.map.${board}.diff done
this is is generally useful, perhaps MAKEALL should grow a flag to back up the
generated files with board-qualified names like the log files ...
then your script would be:
./MAKEALL newflag powerpc
copy all generated files to old/
apply change
./MAKEALL newflag powerpc
compare results
-mike
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] (no subject)
On Wednesday, February 16, 2011 15:27:52 Richard Retanubun wrote: Thanks for the feedback, and for the cool unification. Here is the updated patch that implements your comments and is based on the head of the blackfin.git sf branch. thanks ! i'll try to get to it this weekend, but no promises as i currently have non-u-boot stuff pressing for my time. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] building enc28j60 for omap3: undefined references
On Wednesday, February 16, 2011 12:31:23 Reinhard Meyer wrote: Dear jacopo mondi, I'm using last u-boot, cloned from master branch yesterday. Is my toolchain broken? Not sure, the driver builds fine with ARM boards. and Blackfin boards. btw, not sure if i said this before, but good job with the updated enc2j60 net driver. it rox teh sox. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
