April 2011 - U-Boot

[U-Boot] [PATCH v4 1/3] ARM: MX31: Fix file name label
by Fabio Estevam 21 Apr '11

21 Apr '11

Commit 5d2c154 (IMX: MX31: Cleanup include files and drop nasty #ifdef in drivers) renamed mx31-imx-regs.h to imx-regs.h. Change the file label accordingly. Signed-off-by: Fabio Estevam <fabio.estevam(a)freescale.com> --- This patch series should were applied in the u-boot-arm tree. It also needs the following patch to be applied first: [PATCH v5] ARM: mx31: Print the silicon version arch/arm/include/asm/arch-mx31/imx-regs.h | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm/include/asm/arch-mx31/imx-regs.h b/arch/arm/include/asm/arch-mx31/imx-regs.h index 0eeaf39..74444f2 100644 --- a/arch/arm/include/asm/arch-mx31/imx-regs.h +++ b/arch/arm/include/asm/arch-mx31/imx-regs.h @@ -21,8 +21,8 @@ * MA 02111-1307 USA */ -#ifndef __ASM_ARCH_MX31_REGS_H -#define __ASM_ARCH_MX31_REGS_H +#ifndef __ASM_ARCH_MX31_IMX_REGS_H +#define __ASM_ARCH_MX31_IMX_REGS_H #if !(defined(__KERNEL_STRICT_NAMES) || defined(__ASSEMBLY__)) #include <asm/types.h> @@ -774,4 +774,4 @@ enum iomux_pins { #define MXC_EHCI_IPPUE_DOWN (1 << 8) #define MXC_EHCI_IPPUE_UP (1 << 9) -#endif /* __ASM_ARCH_MX31_REGS_H */ +#endif /* __ASM_ARCH_MX31_IMX_REGS_H */ -- 1.6.0.4

3 6

[U-Boot] [RFC PATCH] arm: provide a CONFIG flag for disabling relocation
by Aneesh V 21 Apr '11

21 Apr '11

Relocation may not be needed and desirable in many cases: * For many boards the amount of SDRAM is fixed. So relocation is not needed. * Relocation adds un-necessary additional overhead when it's not needed. This delay is singificant on slower platforms such as FPGA * Many boards have ample memory. So reserving enough memory for Linux in the first half is not a challenge even without relocation Add a CONFIG option to disable relocation on platforms that do not need it. When this flag is enabled allocate memory for stack heap etc at the end of memory as usual, but U-Boot itself is not moved from TEXT_BASE. Additionally, -pie is removed from the final link step because it was causing the absolute value of all symbols coming from the linker script to be 0. This affects find_cmd() Tested on OMAP4430 SDP Cc: Albert Aribaud <albert.aribaud(a)free.fr> Cc: Wolfgang Denk <wd(a)denx.de> Signed-off-by: Aneesh V <aneesh(a)ti.com> --- arch/arm/config.mk | 2 ++ arch/arm/lib/board.c | 5 +++++ board/ti/sdp4430/config.mk | 9 +++++++-- include/configs/omap4_sdp4430.h | 2 ++ 4 files changed, 16 insertions(+), 2 deletions(-) diff --git a/arch/arm/config.mk b/arch/arm/config.mk index 1785e73..2315bcb 100644 --- a/arch/arm/config.mk +++ b/arch/arm/config.mk @@ -71,5 +71,7 @@ LDSCRIPT := $(SRCTREE)/$(CPUDIR)/u-boot.lds # needed for relocation ifndef CONFIG_NAND_SPL +ifndef CONFIG_SYS_SKIP_ARM_RELOCATION LDFLAGS_u-boot += -pie endif +endif diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c index 72ee108..ed3898f 100644 --- a/arch/arm/lib/board.c +++ b/arch/arm/lib/board.c @@ -361,6 +361,7 @@ void board_init_f (ulong bootflag) gd->fb_base = addr; #endif /* CONFIG_LCD */ +#ifndef CONFIG_SYS_SKIP_ARM_RELOCATION /* * reserve memory for U-Boot code, data & bss * round down to next 4 kB limit @@ -369,6 +370,7 @@ void board_init_f (ulong bootflag) addr &= ~(4096 - 1); debug ("Reserving %ldk for U-Boot at: %08lx\n", gd->mon_len >> 10, addr); +#endif #ifndef CONFIG_PRELOADER /* @@ -420,6 +422,9 @@ void board_init_f (ulong bootflag) dram_init_banksize(); display_dram_config(); /* and display it */ +#ifdef CONFIG_SYS_SKIP_ARM_RELOCATION + addr = _TEXT_BASE; +#endif gd->relocaddr = addr; gd->start_addr_sp = addr_sp; gd->reloc_off = addr - _TEXT_BASE; diff --git a/board/ti/sdp4430/config.mk b/board/ti/sdp4430/config.mk index c62965d..8846732 100644 --- a/board/ti/sdp4430/config.mk +++ b/board/ti/sdp4430/config.mk @@ -28,5 +28,10 @@ # Linux-Kernel is expected to be at 8000'8000, entry 8000'8000 # (mem base + reserved) -# 1MB into the SDRAM to allow for SPL's bss at the beginning of SDRAM -CONFIG_SYS_TEXT_BASE = 0x80100000 +# 64MB into the SDRAM +# Assuming a minimum of 128 MB on the board: +# - 64MB before U-Boot is more than enough for Linux when relocation is +# disabled +# - ~63MB after the U-Boot is more than enough for U-Boot to relocate +# itself without stepping on itself +CONFIG_SYS_TEXT_BASE = 0x84000000 diff --git a/include/configs/omap4_sdp4430.h b/include/configs/omap4_sdp4430.h index fff67d8..e9f76d3 100644 --- a/include/configs/omap4_sdp4430.h +++ b/include/configs/omap4_sdp4430.h @@ -278,4 +278,6 @@ #define CONFIG_SYS_SPL_BSS_MAX_SIZE 0x80000 /* 512 KB */ #define CONFIG_SYS_THUMB_BUILD + +#define CONFIG_SYS_SKIP_ARM_RELOCATION #endif /* __CONFIG_H */ -- 1.7.0.4

4 7

[U-Boot] Notification
by Western Union Money 21 Apr '11

21 Apr '11

Confirm the receipt of $50,000 from western union by filling the details to the Transfer Manager Mr.Eddy James: WESTERN UNION WINNER BIODATAS Form 1. Name: 2. Address 3. Country : 4. Phone Number 5. Occupation: 6. Sex :.. 7. Age

1 0

[U-Boot] (no subject)
by terri nechwa 21 Apr '11

21 Apr '11

NICE TO MEET YOU, How are you today, Hope all is well with you and your family? My name is Miss Terri Nechwa. However it really pleases me to write you for a lovely and sincere friendship even if we haven’t met or seen each other before. I will so much appreciate to see your reply soon so that i can send you my pictures and know more about ourselves. I shall appreciate an urgent response from you, because i have something to discuss with you. With lots of love from your newlover, Miss Terri Nechwa

1 0

Re: [U-Boot] [beagleboard] Re: [PATCH] Add 'led' command
by Jason Kridner 21 Apr '11

21 Apr '11

Adding u-boot list.... seem to have missed it in my reply. On Thu, Apr 21, 2011 at 9:16 AM, Jason Kridner <jkridner(a)beagleboard.org>wrote: > On Wed, Apr 20, 2011 at 6:04 PM, Wolfgang Denk <wd(a)denx.de> wrote: > >> Dear Jason Kridner, >> >> In message <1299013329-29931-1-git-send-email-jkridner(a)beagleboard.org> >> you wrote: >> > This patch allows any board implementing the coloured LED API >> > to control the LEDs from the console. >> > >> > led [green | yellow | red | all ] [ on | off ] >> > >> > or >> > >> > led [ 1 | 2 | 3 | all ] [ on | off ] >> >> I still wonder if such a patch will help to get rid of the ton of LEd >> drivers we already have in U-Boot, or if it just adds another such >> interface? >> > > It neither adds nor subtracts. > > >> >> Which drivers ("led.c" files) will be obsoleted by this patch? >> > > None. The objective is simply to expose led.c functionality to a > command-line function. > > >> >> >> If it is intended to be a generic interface - how can this then be >> combined with the status_led.c driver? >> > > It is intended to utilize status_led.h and therefore to be complementary to > status_led.c. Looking at it right now, it looks like I can better reuse > some functions in that driver, so I will modify the code to do that. My > apologies for missing it. > > >> >> The configuration "green", "yellow", "red" seems to be very specific >> to me - I guess this applies just to very few boards? >> > > Yes, but it is in status_led.h, so I wanted to include the support for it. > > >> >> ... >> > +struct led_tbl_s { >> > + char *string; /* String for use in the command >> */ >> > + led_id_t mask; /* Mask used for calling >> __led_set() */ >> > + void (*on)(void); /* Optional fucntion for turning >> LED on */ >> > + void (*off)(void); /* Optional fucntion for turning >> LED on */ >> > +}; >> > + >> > +typedef struct led_tbl_s led_tbl_t; >> > + >> > +static const led_tbl_t led_commands[] = { >> > +#ifdef CONFIG_BOARD_SPECIFIC_LED >> > +#ifdef STATUS_LED_BIT >> > + { "0", STATUS_LED_BIT, NULL, NULL }, >> > +#endif >> > +#ifdef STATUS_LED_BIT1 >> > + { "1", STATUS_LED_BIT1, NULL, NULL }, >> > +#endif >> > +#ifdef STATUS_LED_BIT2 >> > + { "2", STATUS_LED_BIT2, NULL, NULL }, >> > +#endif >> > +#ifdef STATUS_LED_BIT3 >> > + { "3", STATUS_LED_BIT3, NULL, NULL }, >> > +#endif >> >> What are these "status bits" good for when they have no actual >> handlers attached? Where are they actually used? >> > > If no LED specific handler is provided, __led_set is used. I'm going to > switch this to status_led_set() based on your feedback. > > >> >> >> > +#ifdef STATUS_LED_GREEN >> > + { "green", STATUS_LED_GREEN, green_LED_off, green_LED_on }, >> > +#endif >> > +#ifdef STATUS_LED_YELLOW >> > + { "yellow", STATUS_LED_YELLOW, yellow_LED_off, yellow_LED_on }, >> > +#endif >> > +#ifdef STATUS_LED_RED >> > + { "red", STATUS_LED_RED, red_LED_off, red_LED_on }, >> > +#endif >> > +#ifdef STATUS_LED_BLUE >> > + { "blue", STATUS_LED_BLUE, blue_LED_off, blue_LED_on }, >> > +#endif >> >> We do not allow CamelCase identifiers (like "green_LED_off"). >> > > Easy enough to fix. > > >> >> >> 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 >> Sometimes a man will tell his bartender things he'll never tell his >> doctor. >> -- Dr. Phillip Boyce, "The Menagerie" ("The Cage"), >> stardate unknown. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Beagle Board" group. >> To post to this group, send email to beagleboard(a)googlegroups.com. >> To unsubscribe from this group, send email to >> beagleboard+unsubscribe(a)googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/beagleboard?hl=en. >> >> >

1 1

[U-Boot] [PATCH] cfi_flash driver - Add delay after reset command
by Aaron Williams 21 Apr '11

21 Apr '11

I ran into a problem where the reset was failing except when I enabled debugging support. After talking with Garret Swalling at Spansion I was told that the GL-N series of devices require a 500ns wait for the reset to complete. The below patch adds a 1us delay after all reset commands. -Aaron Williams Signed-off-by: Aaron Williams <aaron.williams(a)caviumnetworks.com> --- drivers/mtd/cfi_flash.c | 7 +++++++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c index 9ee639e..4bc01f7 100644 --- a/drivers/mtd/cfi_flash.c +++ b/drivers/mtd/cfi_flash.c @@ -586,6 +586,7 @@ static int flash_status_check (flash_info_t * info, flash_sect_t sector, prompt, info->start[sector], flash_read_long (info, sector, 0)); flash_write_cmd (info, sector, 0, info->cmd_reset); + udelay(1); return ERR_TIMOUT; } udelay (1); /* also triggers watchdog */ @@ -633,6 +634,7 @@ static int flash_full_status_check (flash_info_t * info, flash_sect_t sector, puts ("Vpp Low Error.\n"); } flash_write_cmd (info, sector, 0, info->cmd_reset); + udelay(1); break; default: break; @@ -1496,6 +1498,7 @@ void flash_read_user_serial (flash_info_t * info, void *buffer, int offset, flash_write_cmd (info, 0, 0, FLASH_CMD_READ_ID); memcpy (dst, src + offset, len); flash_write_cmd (info, 0, 0, info->cmd_reset); + udelay(1); flash_unmap(info, 0, FLASH_OFFSET_USER_PROTECTION, src); } @@ -1511,6 +1514,7 @@ void flash_read_factory_serial (flash_info_t * info, void *buffer, int offset, flash_write_cmd (info, 0, 0, FLASH_CMD_READ_ID); memcpy (buffer, src + offset, len); flash_write_cmd (info, 0, 0, info->cmd_reset); + udelay(1); flash_unmap(info, 0, FLASH_OFFSET_INTEL_PROTECTION, src); } @@ -1542,6 +1546,7 @@ static void cfi_reverse_geometry(struct cfi_qry *qry) static void cmdset_intel_read_jedec_ids(flash_info_t *info) { flash_write_cmd(info, 0, 0, FLASH_CMD_RESET); + udelay(1); flash_write_cmd(info, 0, 0, FLASH_CMD_READ_ID); udelay(1000); /* some flash are slow to respond */ info->manufacturer_id = flash_read_uchar (info, @@ -1610,6 +1615,7 @@ static void cmdset_amd_read_jedec_ids(flash_info_t *info) break; } flash_write_cmd(info, 0, 0, AMD_CMD_RESET); + udelay(1); } static int cmdset_amd_init(flash_info_t *info, struct cfi_qry *qry) @@ -1736,6 +1742,7 @@ void __flash_cmd_reset(flash_info_t *info) * that AMD flash roms ignore the Intel command. */ flash_write_cmd(info, 0, 0, AMD_CMD_RESET); + udelay(1); flash_write_cmd(info, 0, 0, FLASH_CMD_RESET); } void flash_cmd_reset(flash_info_t *info) -- 1.7.3.4

2 1

[U-Boot] [PATCH] mtd, cfi: read AMD 3-byte (expanded) device ids on 16bit devices
by Heiko Schocher 21 Apr '11

21 Apr '11

Signed-off-by: Heiko Schocher <hs(a)denx.de> --- drivers/mtd/cfi_flash.c | 13 +++++++++++-- 1 files changed, 11 insertions(+), 2 deletions(-) diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c index 5788328..7617e0e 100644 --- a/drivers/mtd/cfi_flash.c +++ b/drivers/mtd/cfi_flash.c @@ -1202,8 +1202,9 @@ void flash_print_info (flash_info_t * info) info->manufacturer_id); printf (info->chipwidth == FLASH_CFI_16BIT ? "%04X" : "%02X", info->device_id); - if (info->device_id == 0x7E) { - printf("%04X", info->device_id2); + if ((info->device_id & 0xff) == 0x7E) { + printf(info->chipwidth == FLASH_CFI_16BIT ? "%04X" : "%02X", + info->device_id2); } printf ("\n Erase timeout: %ld ms, write timeout: %ld ms\n", info->erase_blk_tout, @@ -1599,6 +1600,14 @@ static void cmdset_amd_read_jedec_ids(flash_info_t *info) case FLASH_CFI_16BIT: info->device_id = flash_read_word (info, FLASH_OFFSET_DEVICE_ID); + if ((info->device_id & 0xff) == 0x7E) { + /* AMD 3-byte (expanded) device ids */ + info->device_id2 = flash_read_uchar (info, + FLASH_OFFSET_DEVICE_ID2); + info->device_id2 <<= 8; + info->device_id2 |= flash_read_uchar (info, + FLASH_OFFSET_DEVICE_ID3); + } break; default: break; -- 1.7.4

2 3

[U-Boot] [PATCH] cfi_flash: reverse geometry for M29W800DT parts
by Mike Frysinger 21 Apr '11

21 Apr '11

The M29W800DT parts also report their geometry with the sector layout reversed. So add that ID to the flash_fixup_stm function. Otherwise, we get: bfin> flinfo Bank # 1: CFI conformant FLASH (16 x 16) Size: 1 MB in 19 Sectors AMD Standard command set, Manufacturer ID: 0x20, Device ID: 0x22D7 Erase timeout: 8192 ms, write timeout: 1 ms Sector Start Addresses: 20000000 20004000 20006000 20008000 20010000 20020000 20030000 20040000 20050000 20060000 20070000 20080000 20090000 200A0000 200B0000 200C0000 200D0000 200E0000 200F0000 Reported-by: Jianxi Fu <fujianxi(a)gmail.com> Signed-off-by: Mike Frysinger <vapier(a)gentoo.org> --- drivers/mtd/cfi_flash.c | 7 ++++--- 1 files changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c index 0909fe7..69f12d3 100644 --- a/drivers/mtd/cfi_flash.c +++ b/drivers/mtd/cfi_flash.c @@ -1852,9 +1852,10 @@ static void flash_fixup_stm(flash_info_t *info, struct cfi_qry *qry) if (qry->num_erase_regions > 1) { /* reverse geometry if top boot part */ if (info->cfi_version < 0x3131) { - /* CFI < 1.1, guess by device id (M29W320{DT,ET} only) */ - if (info->device_id == 0x22CA || - info->device_id == 0x2256) { + /* CFI < 1.1, guess by device id */ + if (info->device_id == 0x22CA || /* M29W320DT */ + info->device_id == 0x2256 || /* M29W320ET */ + info->device_id == 0x22D7) { /* M29W800DT */ cfi_reverse_geometry(qry); } } -- 1.7.5.rc1

3 2

[U-Boot] The forbidden value in omap3-common timer.c code
by Simon Schwarz 21 Apr '11

21 Apr '11

Hi there, I just started to work with the u-boot sources for my bachelor thesis. There was a part in the source which irritated me a bit. I talk about ./arch/arm/cpu/armv7/omap-common/timer.c It's about that part of code: #define TIMER_LOAD_VAL 0xffffffff int timer_init(void) { /* start the counter ticking up, reload value on overflow */ writel(TIMER_LOAD_VAL, &timer_base->tldr); /* enable timer */ writel((CONFIG_SYS_PTV << 2) | TCLR_PRE | TCLR_AR | TCLR_ST, &timer_base->tclr); reset_timer_masked(); /* init the timestamp and lastinc value */ return 0; } The tldr ist loaded with 0xFFFFFFFF. The OMAP35x Technical Reference Manual (Rev. P) says on page 2583: Do not put the overflow value (0xFFFFFFFF) in the GPTi.TLDR register because it can lead to undesired results. Is there a reason why the value is used nevertheless? At this time I don't know where the timer is used, maybe the "undesired results" haven't been noticed yet? Thanks! Simon -- ------------------------------------------------- Simon Schwarz Corscience GmbH& Co. KG Henkestraße 91 D-91052 Erlangen e-mail: schwarz(a)corscience.de Internet: www.corscience.de ------------------------------------------------- Corscience GmbH& Co.KG Sitz der Gesellschaft/Place of business: Erlangen Amtsgericht/Local court: Fürth Handelsregisternummer/Commercial Register No.: HRA 7510 Geschäftsführer/Managing director: Prof. Dr. Armin Bolz, Dr. Karl-Andreas Feldhahn, Dipl.-Volksw. Marc Griefahn CONFIDENTIALITY: This e-mail and any attachments are confidential and may also be privileged. If received in error, please do not disclose the contents to anyone, but notify us immediately by return e-mail and delete this e-mail and any attachments from your system. Thank you.

2 1

[U-Boot] OPEN THE ATTACHMENT AND READ YOUR LETTER
by South African Reserve Bank 21 Apr '11

21 Apr '11

1 0