October 2010 - U-Boot

[U-Boot] [PATCH] xyzModem.c Packet buffer dynamic allocate
by Yoshinori Sato 01 Oct '10

01 Oct '10

Hello. It changes reduce bss usage. Ymodem receive buffer dinamic allocation. Signed-off-by: Yoshinori Sato <ysato(a)users.sourceforge.jp> --- common/cmd_load.c | 1 + common/xyzModem.c | 17 ++++++++++++++--- 2 files changed, 15 insertions(+), 3 deletions(-) diff --git a/common/cmd_load.c b/common/cmd_load.c index dad0303..f144bf4 100644 --- a/common/cmd_load.c +++ b/common/cmd_load.c @@ -992,6 +992,7 @@ static ulong load_serial_ymodem (ulong offset) store_addr, res); if (rc != 0) { flash_perror (rc); + xyzModem_stream_close (&err); return (~0); } } else diff --git a/common/xyzModem.c b/common/xyzModem.c index 7a46805..5af995d 100644 --- a/common/xyzModem.c +++ b/common/xyzModem.c @@ -58,6 +58,7 @@ #include <xyzModem.h> #include <stdarg.h> #include <crc.h> +#include <malloc.h> /* Assumption - run xyzModem protocol over the console port */ @@ -81,7 +82,7 @@ static struct #else int *__chan; #endif - unsigned char pkt[1024], *bufp; + unsigned char *pkt, *bufp; unsigned char blk, cblk, crc1, crc2; unsigned char next_blk; /* Expected block */ int len, mode, total_retries; @@ -353,6 +354,7 @@ xyzModem_get_hdr (void) bool hdr_found = false; int i, can_total, hdr_chars; unsigned short cksum; + char *pktp; ZM_DEBUG (zm_new ()); /* Find the start of a header */ @@ -433,13 +435,14 @@ xyzModem_get_hdr (void) } xyz.len = (c == SOH) ? 128 : 1024; xyz.bufp = xyz.pkt; + pktp = xyz.pkt; for (i = 0; i < xyz.len; i++) { res = CYGACC_COMM_IF_GETC_TIMEOUT (*xyz.__chan, &c); ZM_DEBUG (zm_save (c)); if (res) { - xyz.pkt[i] = c; + *pktp++ = c; } else { @@ -489,9 +492,10 @@ xyzModem_get_hdr (void) else { cksum = 0; + pktp = xyz.pkt; for (i = 0; i < xyz.len; i++) { - cksum += xyz.pkt[i]; + cksum += *pktp++; } if (xyz.crc1 != (cksum & 0xFF)) { @@ -560,6 +564,11 @@ xyzModem_stream_open (connection_info_t * info, int *err) xyz.read_length = 0; xyz.file_length = 0; #endif + if (xyz.pkt == NULL) { + xyz.pkt = malloc(1024); + if (xyz.pkt == NULL) + return -1; + } CYGACC_COMM_IF_PUTC (*xyz.__chan, (xyz.crc_mode ? 'C' : NAK)); @@ -743,6 +752,8 @@ xyzModem_stream_close (int *err) xyz.crc_mode ? "CRC" : "Cksum", xyz.total_SOH, xyz.total_STX, xyz.total_CAN, xyz.total_retries); ZM_DEBUG (zm_flush ()); + free(xyz.pkt); + xyz.pkt = NULL; } /* Need to be able to clean out the input buffer, so have to take the */ -- 1.7.1

3 3

[U-Boot] ARMV7: OMAP3: Fix bug in get_sdr_cs_offset()
by Steve Sakoman 01 Oct '10

01 Oct '10

This patch fixes a typo in the routine to calculate the cs offset based upon the contents of the SDRC cs_cfg register. This function mistakenly shifts the CS1STARTLOW field 17 bits right instead of 17 bits left. This hasn't been an issue to date because all OMAP3 boards currently are configured to have zeros in this field. Reported-by: Peter Maydell <peter.maydell(a)linaro.org> Signed-off-by: Steve Sakoman <steve(a)sakoman.com> --- diff --git a/arch/arm/cpu/armv7/omap3/sdrc.c b/arch/arm/cpu/armv7/omap3/sdrc.c index 2719bb5..6c419f5 100644 --- a/arch/arm/cpu/armv7/omap3/sdrc.c +++ b/arch/arm/cpu/armv7/omap3/sdrc.c @@ -99,7 +99,7 @@ u32 get_sdr_cs_offset(u32 cs) return 0; offset = readl(&sdrc_base->cs_cfg); - offset = (offset & 15) << 27 | (offset & 0x30) >> 17; + offset = (offset & 15) << 27 | (offset & 0x30) << 17; return offset; }

1 0

[U-Boot] [RFC] move nand_init after pci_init in arch/powerpc/lib/board.c ?
by André Schwarz 01 Oct '10

01 Oct '10

Actually I'm trying to implement a simple bitbanged Nand-Flash device connected to a PCI FPGA. I'm running latest U-Boot on mvBL-M7 board (MPC8343). Unfortunately nand_init() gets called before pci_init() within arch/powerpc/lib/board.c ? Is there any possibility to defer nand_init after pci_init ? To minimize impact we could introduce a second nand_init after pci_init depending on e.g. CONFIG_NAND_LATE_INIT ... of course being mutually exclusive with the first instance. Regards, André MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner

2 1

[U-Boot] u-boot on dockstar problem - ** Bad partition 1 **
by devzero＠web.de 01 Oct '10

01 Oct '10

Wolfgang, to be honest, it`s not my problem that some people on the net seem to be on a personal crusade to tell other people how to post to mailinglists or how to write email. My life does not depend on u-boot. I did not only ask for help, but i also offered help (giving valuable end-user input to make u-boot run better on pogoplug/dockstar - Mind that dockstar is currently on sale at Atelco for Eur 24,90. That is a killer price for 1,2Ghz ARM Kirkwood SoC with 128M) If you don`t like me or like my mail style - no problem, i can go away and switch to another bootloader or maybe even other hardware platform. What I got from you for my postings was nothing but negative. I was being accused that I did not this or I did not that. In other words, you even told me to be an idiot, as I should go read a document how to ask SMART questions. So, if this list is also for users, I would recommend to be more tolerant on how users write mails! I`m no C-coder and there are people in this world that give not that much attention to make their Ascii look perfect on screen. Don`t you think that those two mails from you were a little bit more offensive than my laxly dealing with mail formatting was offensive to all the list members alltogether ? I don`t even know how to limit chars in my webmailer, and even Linus Torvalds is fine with more than 80 chars per line (http://lkml.org/lkml/2009/12/17/229 ) So, we either can say a friendly "Hello" now, or you may kick me off this list and scare me away from u-boot for the rest of my life. Sorry if that have been harsh words now, but i was really pissed and it is a very long time ago that is got such negative response from a project`s owner to initial postings on a mailing list. If we can be above such things now, i suggest we concentrate on the issue. If you`re ok with that, here we go (otherwise: please ignore!): > You completely fail to explain which exact version of U-Boot you are > running - it seems to be a locally modified one, probably with > out-of-tree patches to support that Dockstar board which is not known > in the mainline U-Boot repository. How should we be able to comment > on code we don't even know? Apparently you are right. I did not realize that this is a modified version ( http://jeff.doozan.com/debian/uboot/build_uboot.htm ) and apparently the changes (add pogoplug/dockstar, seems much LED stuff) have never been sent upstream. Anyway,the patch at http://jeff.doozan.com/debian/uboot/uboot.mtd3.patch does not seem to poke into the u-boot usb code, so i wonder if the changes can be source of the problem. I have seen posts from sheevaplug users which report similar issue, and as it seems, official support for sheevaplug is already in u-boot. Maybe there is a way to add official support for pogoplug and dockstar, as this out-of-tree stuff sucks big.... So, if this is not for the u-boot list, please somebody give an advice on how to proceed for resolving this issue. regards Roland ps: reference to the initial post, unintentionally hijacking another thread: http://lists.denx.de/pipermail/u-boot/2010-September/077489.html From: "Wolfgang Denk" <wd(a)denx.de> Sent: Tuesday, September 21, 2010 8:40 AM To: <devzero(a)web.de> Cc: Subject: Re: [U-Boot] [PATCH] usb: fix usb start problem with SMSC USB hub and Toshiba USB stick > Dear devzero(a)web.de, > > In message <899533205.349626.1285022229052.JavaMail.fmail@mwmweb063> you wrote: >> pardon, that was not my intention, nor was it my intention to infringe list >> rules. so, this is for developers/experts - not for users and bug-reporte >> rs? > > This list is for ALL discussions about U-Boot: users, bug-reporters, > developers, etc. > > But we expect that everybody who posts here follows some basic > Netiquette. > > You don't. For example, Netiquette says to keep your line length below > some 70 characters or so. > > You don't even after being told. I asked you explicitly NOT to top > post / full quote, and pointed you to rules for correct quoting. You > ignore that. > >> i`m spending more than half of this evening with this issue, trying to find >> a solution and trying to provide information for a problem affecting manyr >> people and which seems to exist in u-boot. > > I also pointed you to a document that explains how to ask smart > questions, but it seems you ignored this hint as well. > > You completely fail to explain which exact version of U-Boot you are > running - it seems to be a locally modified one, probably with > out-of-tree patches to support that Dockstar board which is not known > in the mainline U-Boot repository. How should we be able to comment > on code we don't even know? > > 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: wd(a)denx.de > "Have you lived in this village all your life?" "No, not yet." ___________________________________________________________ Neu: WEB.DE De-Mail - Einfach wie E-Mail, sicher wie ein Brief! Jetzt De-Mail-Adresse reservieren: https://produkte.web.de/go/demail02

3 6

[U-Boot] silencing i2c dev?
by Frans Meulenbroeks 01 Oct '10

01 Oct '10

If I run i2c dev to set the bus it replies what it did: => i2c dev 0 Setting bus to 0 Other commands do not seem to do that. e.g. mw does not tell it has written a value. Should we make i2c dev silent too? (I'm using this in a script and want to avoid superfluous messages). If desired I can submit a patch. Btw there might also be a parsing issue. I once mistyped the cmd but still it worked: => i2c de v0 Setting bus to 0 Haven't had time to dig into this Frans

2 1

[U-Boot] [PATCH] Kirkwood: dram_init is moved to dram.c
by Prafulla Wadaskar 01 Oct '10

01 Oct '10

For all Kirkwood boards so far dram_init function is duplicated dram_init function is moved to dram.c and relevant code from all board specific files removed If any board needs specific dram init handling than standard one, then, a macro CONFIG_SYS_BOARD_DRAM_INIT should be defined in board config header file and the dram_init function can be put in board specific source file For ex. keymile boards Signed-off-by: Prafulla Wadaskar <prafulla(a)marvell.com> --- arch/arm/cpu/arm926ejs/kirkwood/dram.c | 22 ++++++++++++++++++++++ board/Marvell/guruplug/guruplug.c | 11 ----------- board/Marvell/mv88f6281gtw_ge/mv88f6281gtw_ge.c | 11 ----------- board/Marvell/openrd_base/openrd_base.c | 11 ----------- board/Marvell/rd6281a/rd6281a.c | 11 ----------- board/Marvell/sheevaplug/sheevaplug.c | 11 ----------- include/configs/keymile-common.h | 1 + 7 files changed, 23 insertions(+), 55 deletions(-) diff --git a/arch/arm/cpu/arm926ejs/kirkwood/dram.c b/arch/arm/cpu/arm926ejs/kirkwood/dram.c index 8f2a18a..d929d7a 100644 --- a/arch/arm/cpu/arm926ejs/kirkwood/dram.c +++ b/arch/arm/cpu/arm926ejs/kirkwood/dram.c @@ -23,8 +23,11 @@ */ #include <config.h> +#include <common.h> #include <asm/arch/kirkwood.h> +DECLARE_GLOBAL_DATA_PTR; + #define KW_REG_CPUCS_WIN_BAR(x) (KW_REGISTER(0x1500) + (x * 0x08)) #define KW_REG_CPUCS_WIN_SZ(x) (KW_REGISTER(0x1504) + (x * 0x08)) /* @@ -56,3 +59,22 @@ u32 kw_sdram_bs(enum memory_bank bank) result += 0x01000000; return result; } + +#ifndef CONFIG_SYS_BOARD_DRAM_INIT +int dram_init(void) +{ + int i; +#if !defined(CONFIG_SYS_ARM_WITHOUT_RELOC) + gd->ram_size = 0; +#endif + for (i = 0; i < CONFIG_NR_DRAM_BANKS; i++) { + gd->bd->bi_dram[i].start = kw_sdram_bar(i); + gd->bd->bi_dram[i].size = kw_sdram_bs(i); +#if !defined(CONFIG_SYS_ARM_WITHOUT_RELOC) + gd->ram_size += gd->bd->bi_dram[i].size; +#endif + } + return 0; +} +#endif /* CONFIG_SYS_KWDRAM_INIT */ + diff --git a/board/Marvell/guruplug/guruplug.c b/board/Marvell/guruplug/guruplug.c index c028a53..4df4e9b 100644 --- a/board/Marvell/guruplug/guruplug.c +++ b/board/Marvell/guruplug/guruplug.c @@ -108,17 +108,6 @@ int board_init(void) return 0; } -int dram_init(void) -{ - int i; - - for (i = 0; i < CONFIG_NR_DRAM_BANKS; i++) { - gd->bd->bi_dram[i].start = kw_sdram_bar(i); - gd->bd->bi_dram[i].size = kw_sdram_bs(i); - } - return 0; -} - #ifdef CONFIG_RESET_PHY_R void mv_phy_88e1121_init(char *name) { diff --git a/board/Marvell/mv88f6281gtw_ge/mv88f6281gtw_ge.c b/board/Marvell/mv88f6281gtw_ge/mv88f6281gtw_ge.c index c959bf8..93d1400 100644 --- a/board/Marvell/mv88f6281gtw_ge/mv88f6281gtw_ge.c +++ b/board/Marvell/mv88f6281gtw_ge/mv88f6281gtw_ge.c @@ -110,17 +110,6 @@ int board_init(void) return 0; } -int dram_init(void) -{ - int i; - - for (i = 0; i < CONFIG_NR_DRAM_BANKS; i++) { - gd->bd->bi_dram[i].start = kw_sdram_bar(i); - gd->bd->bi_dram[i].size = kw_sdram_bs(i); - } - return 0; -} - #ifdef CONFIG_MV88E61XX_SWITCH void reset_phy(void) { diff --git a/board/Marvell/openrd_base/openrd_base.c b/board/Marvell/openrd_base/openrd_base.c index c00a08a..d006b2d 100644 --- a/board/Marvell/openrd_base/openrd_base.c +++ b/board/Marvell/openrd_base/openrd_base.c @@ -113,17 +113,6 @@ int board_init(void) return 0; } -int dram_init(void) -{ - int i; - - for (i = 0; i < CONFIG_NR_DRAM_BANKS; i++) { - gd->bd->bi_dram[i].start = kw_sdram_bar(i); - gd->bd->bi_dram[i].size = kw_sdram_bs(i); - } - return 0; -} - #ifdef CONFIG_RESET_PHY_R /* Configure and enable MV88E1116 PHY */ void reset_phy(void) diff --git a/board/Marvell/rd6281a/rd6281a.c b/board/Marvell/rd6281a/rd6281a.c index 8713a3c..0d76146 100644 --- a/board/Marvell/rd6281a/rd6281a.c +++ b/board/Marvell/rd6281a/rd6281a.c @@ -109,17 +109,6 @@ int board_init(void) return 0; } -int dram_init(void) -{ - int i; - - for (i = 0; i < CONFIG_NR_DRAM_BANKS; i++) { - gd->bd->bi_dram[i].start = kw_sdram_bar(i); - gd->bd->bi_dram[i].size = kw_sdram_bs(i); - } - return 0; -} - void mv_phy_88e1116_init(char *name) { u16 reg; diff --git a/board/Marvell/sheevaplug/sheevaplug.c b/board/Marvell/sheevaplug/sheevaplug.c index 547126a..173a7b8 100644 --- a/board/Marvell/sheevaplug/sheevaplug.c +++ b/board/Marvell/sheevaplug/sheevaplug.c @@ -108,17 +108,6 @@ int board_init(void) return 0; } -int dram_init(void) -{ - int i; - - for (i = 0; i < CONFIG_NR_DRAM_BANKS; i++) { - gd->bd->bi_dram[i].start = kw_sdram_bar(i); - gd->bd->bi_dram[i].size = kw_sdram_bs(i); - } - return 0; -} - #ifdef CONFIG_RESET_PHY_R /* Configure and enable MV88E1116 PHY */ void reset_phy(void) diff --git a/include/configs/keymile-common.h b/include/configs/keymile-common.h index 6c14ca0..62d21f6 100644 --- a/include/configs/keymile-common.h +++ b/include/configs/keymile-common.h @@ -85,6 +85,7 @@ #define CONFIG_LOADS_ECHO 1 /* echo on for serial download */ #define CONFIG_SYS_LOADS_BAUD_CHANGE 1 /* allow baudrate change */ +#define CONFIG_SYS_BOARD_DRAM_INIT /* Used board specific dram_init */ /* * How to get access to the slot ID. Put this here to make it easy -- 1.5.3.3

6 25

[U-Boot] [PATCH V3 1/2] [NEXT] arm: change relocation flag from -fPIC to -fPIE
by Albert Aribaud 01 Oct '10

01 Oct '10

Replace GOT indirect addressing with more efficient pic-base relative addressing for initialized data (uninitialized data still use GOTi indirect addressing). This also reduces code size by 0.4% compared to -fPIC. Signed-off-by: Albert Aribaud <albert.aribaud(a)free.fr> --- SUMMARY This patch aims at optimizing relocatable code both in size and speed. The first patch switches from '-fPIC' to '-fPIE', which makes initialized data accesses pc-relative rather than GOT-indirect, and the second adds '-msingle-pic-base' which factors out GOT addressing by computing it once and for all. PATCHSET HISTORY V1 Initial submission V2 Compute RAM pic base only if actually relocating Fixed RAM pic base computation and copy loop V3 Added fix for tx25 arch/arm/config.mk | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/config.mk b/arch/arm/config.mk index 6923f6d..138c43a 100644 --- a/arch/arm/config.mk +++ b/arch/arm/config.mk @@ -35,7 +35,7 @@ endif ifndef CONFIG_SYS_ARM_WITHOUT_RELOC # needed for relocation -PLATFORM_RELFLAGS += -fPIC +PLATFORM_RELFLAGS += -fPIE endif ifdef CONFIG_SYS_ARM_WITHOUT_RELOC -- 1.7.0.4

6 12

[U-Boot] [PATCH] ARMV7: OMAP3: Remove unnecessary #undef from Beagle config
by Steve Sakoman 01 Oct '10

01 Oct '10

This patch removes #undef CONFIG_SYS_ARM_WITHOUT_RELOC from the Beagle config file Signed-off-by: Steve Sakoman <steve(a)sakoman.com> --- diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h index cd3ac20..29ce67c 100644 --- a/include/configs/omap3_beagle.h +++ b/include/configs/omap3_beagle.h @@ -337,8 +337,6 @@ extern unsigned int boot_flash_sec; extern unsigned int boot_flash_type; #endif -/* additions for new relocation code, must added to all boards */ -#undef CONFIG_SYS_ARM_WITHOUT_RELOC /* This board is tested with relocation support */ #define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM_1 #define CONFIG_SYS_INIT_SP_ADDR (LOW_LEVEL_SRAM_STACK - CONFIG_SYS_GBL_DATA_SIZE)

2 1

[U-Boot] Loan offer.apply now while offer last.
by JORDAN GLOBAL LOAN CORPORATION 01 Oct '10

01 Oct '10

Dear prospective customer, This is to inform you that Jordan Global Loan Corporation here in Jordan has began a loan program to any one who might be in need of a loan for any financial concern. Should you be interested in applying for a business, Home Improvement, Investment Loan, Debt Consolidation? /mortgage or personal loan, you are required to send an inquiry to us for further proceedings via (jglc3(a)w.cn). Yours Faithfully, Mrs. Fatima Khaled Online advert coordinator Tel: (+962) 795 475 716

1 0