December 2010 - U-Boot

[U-Boot] Which Version of Cross-Compiler should i choose?
by sohu 31 Dec '10

31 Dec '10

Hello,everybody,i am new to uboot. now i choose v2010.09-rc2 Uboot for porting. I used to compiling uboot1.1.2 by arm-elf-20050511 and works well.Now i do not know which version of arm cross-compiler to choose? Any suggestions are appreciated ! Thanks all . By MrGates

1 0

[U-Boot] {Spam?} u-boot relocation
by Marcel 30 Dec '10

30 Dec '10

Hi, I updated my u-boot-usb to continue my work on the SAM9 USB parts, but got stuck with the following issue : There seems to be a new relocation scheme. I also added some stuff to make it detect the SDRAM, but than I get stuck. int dram_init(void) { gd->bd->bi_dram[0].start = PHYS_SDRAM; gd->bd->bi_dram[0].size = PHYS_SDRAM_SIZE; /* dram_init must store complete ramsize in gd->ram_size */ gd->ram_size = get_ram_size((volatile void *)PHYS_SDRAM, PHYS_SDRAM_SIZE); dram_init_banksize(); return 0; } Booting looks like this : U-Boot 2010.12-09749-g8da60f4-dirty (Dec 25 2010 - 18:44:18) U-Boot code: 73F00000 -> 73F3F6F4 BSS: -> 73F51A8C monitor len: 00051A8C ramsize: 08000000 TLB table at: 77ff0000 Top of RAM usable for U-Boot at: 77ff0000 Reserving 326k for U-Boot at: 77f9e000 Reserving 384k for malloc() at: 77f3e000 Reserving 24 Bytes for Board Info at: 77f3dfe8 Reserving 144 Bytes for Global Data at: 77f3df58 New Stack Pointer is: 77f3df50 RAM Configuration: Bank #0: 70000000 128 MiB relocation Offset is: 0409e000 Here it stopsand although I have been reading the relocation readme, it doesn't give me any clues where to look for. My board has 1M NOR flash which holds u-boot. I read something in the readme about it, which makes me believe I need some additional things. Does anyone have an idea what I can do to get this to boot again ? Best regards, Marcel

4 8

[U-Boot] [PATCH 1/2] Blackfin: bfin_sdh: set all timer bits before transfer
by Mike Frysinger 30 Dec '10

30 Dec '10

From: Cliff Cai <cliff.cai(a)analog.com> The timer register is 32bits, not 16bit, so 0xFFFF won't fill it. Write out -1 to make sure to fill the whole thing. Signed-off-by: Cliff Cai <cliff.cai(a)analog.com> Signed-off-by: Mike Frysinger <vapier(a)gentoo.org> --- drivers/mmc/bfin_sdh.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/mmc/bfin_sdh.c b/drivers/mmc/bfin_sdh.c index 5670939..f9da6a3 100644 --- a/drivers/mmc/bfin_sdh.c +++ b/drivers/mmc/bfin_sdh.c @@ -123,7 +123,7 @@ static int sdh_setup_data(struct mmc *mmc, struct mmc_data *data) bfin_write_SDH_DATA_CTL(data_ctl); dma_cfg = WDSIZE_32 | RESTART | WNR | DMAEN; - bfin_write_SDH_DATA_TIMER(0xFFFF); + bfin_write_SDH_DATA_TIMER(-1); blackfin_dcache_flush_invalidate_range(data->dest, data->dest + data->blocksize); -- 1.7.3.4

1 1

[U-Boot] [PATCH] OMAP: Remove omapfb.debug=y from Beagle and Overo env settings
by Steve Sakoman 30 Dec '10

30 Dec '10

The kernel DSS2 code is mature now, and keeping this setting hurts performance Signed-off-by: Steve Sakoman <steve(a)sakoman.com> --- diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h index 56363f7..d0ef313 100644 --- a/include/configs/omap3_beagle.h +++ b/include/configs/omap3_beagle.h @@ -203,7 +203,6 @@ "mpurate=${mpurate} " \ "vram=${vram} " \ "omapfb.mode=dvi:${dvimode} " \ - "omapfb.debug=y " \ "omapdss.def_disp=${defaultdisplay} " \ "root=${mmcroot} " \ "rootfstype=${mmcrootfstype}\0" \ @@ -211,7 +210,6 @@ "mpurate=${mpurate} " \ "vram=${vram} " \ "omapfb.mode=dvi:${dvimode} " \ - "omapfb.debug=y " \ "omapdss.def_disp=${defaultdisplay} " \ "root=${nandroot} " \ "rootfstype=${nandrootfstype}\0" \ diff --git a/include/configs/omap3_overo.h b/include/configs/omap3_overo.h index 3b53796..74b2ff0 100644 --- a/include/configs/omap3_overo.h +++ b/include/configs/omap3_overo.h @@ -169,7 +169,6 @@ "mpurate=${mpurate} " \ "vram=${vram} " \ "omapfb.mode=dvi:${dvimode} " \ - "omapfb.debug=y " \ "omapdss.def_disp=${defaultdisplay} " \ "root=${mmcroot} " \ "rootfstype=${mmcrootfstype}\0" \ @@ -177,7 +176,6 @@ "mpurate=${mpurate} " \ "vram=${vram} " \ "omapfb.mode=dvi:${dvimode} " \ - "omapfb.debug=y " \ "omapdss.def_disp=${defaultdisplay} " \ "root=${nandroot} " \ "rootfstype=${nandrootfstype}\0" \

1 0

[U-Boot] [PATCH 1/2] pci: Add find_hose_by_cfg_addr() helper function
by Kumar Gala 30 Dec '10

30 Dec '10

Being able to get back a pci_controller struct back by searching for it means we can do things like dynamically allocate them or not have to expose the static structures to all users. Signed-off-by: Kumar Gala <galak(a)kernel.crashing.org> --- drivers/pci/pci.c | 11 +++++++++++ include/pci.h | 1 + 2 files changed, 12 insertions(+), 0 deletions(-) diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index 702ac67..74ef4ec 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -165,6 +165,17 @@ struct pci_controller *pci_bus_to_hose (int bus) return NULL; } +struct pci_controller *find_hose_by_cfg_addr(void *cfg_addr) +{ + struct pci_controller *hose; + + for (hose = hose_head; hose; hose = hose->next) + if (hose->cfg_addr == cfg_addr) + return hose; + + return NULL; +} + int pci_last_busno(void) { struct pci_controller *hose = hose_head; diff --git a/include/pci.h b/include/pci.h index c456006..e80b6bd 100644 --- a/include/pci.h +++ b/include/pci.h @@ -511,6 +511,7 @@ extern int pci_hose_write_config_word_via_dword(struct pci_controller *hose, extern void *pci_map_bar(pci_dev_t pdev, int bar, int flags); extern void pci_register_hose(struct pci_controller* hose); extern struct pci_controller* pci_bus_to_hose(int bus); +extern struct pci_controller *find_hose_by_cfg_addr(void *cfg_addr); extern int pci_hose_scan(struct pci_controller *hose); extern int pci_hose_scan_bus(struct pci_controller *hose, int bus); -- 1.7.2.3

1 2

[U-Boot] OMAP3: EVM: Linker errors across tool chain versions
by Dirk Behme 30 Dec '10

30 Dec '10

What's the status of the linker errors across tool chain versions seen by building the 'omap3_evm' board? This was already discussed in the threads [1] and [2], but it seems to me that there was no acceptable fix, yet? E.g. with CodeSourcery's tool chain 2009q1-203 I get arm-none-linux-gnueabi-ld: section .bss [8003f5e0 -> 8007e33f] overlaps section .rel.dyn [8003f5e0 -> 80044e6f] arm-none-linux-gnueabi-ld: section .dynsym [80044e70 -> 80044f0f] overlaps section .bss [8003f5e0 -> 8007e33f] arm-none-linux-gnueabi-ld: u-boot: section .bss vma 0x8003f5e0 overlaps previous sections What we learned from [2] is that using [3] fixes the build (at least for me with the tool chain mentioned above). I.e. converting omap3_evm_version from u8 to int -static u8 omap3_evm_version; +static int omap3_evm_version; makes the issue disappear. But if I understood the discussion correctly, this is no acceptable fix and can be used only as debug help (?). Any further hints? Thanks Dirk [1] ARMv7: Fix linker errors across toolchain versions http://lists.denx.de/pipermail/u-boot/2010-December/082874.html [2] omap3evm: Clean-up EVM detection code http://lists.denx.de/pipermail/u-boot/2010-December/082950.html [3] board/ti/evm/evm.c | 4 ++-- board/ti/evm/evm.h | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) Index: u-boot.git/board/ti/evm/evm.c =================================================================== --- u-boot.git.orig/board/ti/evm/evm.c +++ u-boot.git/board/ti/evm/evm.c @@ -37,9 +37,9 @@ #include <asm/mach-types.h> #include "evm.h" -static u8 omap3_evm_version; +static int omap3_evm_version; -u8 get_omap3_evm_rev(void) +int get_omap3_evm_rev(void) { return omap3_evm_version; } Index: u-boot.git/board/ti/evm/evm.h =================================================================== --- u-boot.git.orig/board/ti/evm/evm.h +++ u-boot.git/board/ti/evm/evm.h @@ -45,7 +45,7 @@ enum { OMAP3EVM_BOARD_GEN_2, /* EVM Rev >= Rev E */ }; -u8 get_omap3_evm_rev(void); +int get_omap3_evm_rev(void); #if defined(CONFIG_CMD_NET) static void setup_net_chip(void);

5 14

[U-Boot] We Offer Private, Commercial and Personal Loans with Minimal annual Interest of 3% to any part of the world.
by m-romano＠sbcglobal.net 30 Dec '10

30 Dec '10

Our loans within the range of $20,000 to $200,000,000 USD. Interested Persons should contact me via E-mail:

1 0

[U-Boot] Regarding the config.mk in U-boot TOP directory
by Asokan, Shyama Trikkadeeri 30 Dec '10

30 Dec '10

Hi Wolfgang, I have been facing an issue while building u-boot for AT91SAM9263ek board. The environment I am using is CYGWIN and toolchain is the Code sourcery toolchain. The make configuration step works fine while "make CROSS_COMPILE " step throws the following error: make CROSS_COMPILE=arm-none-linux-gnueabi- Generating include/autoconf.mk include/common.h:37: fatal error: config.h: No such file or directory compilation terminated. Generating include/autoconf.mk.dep include/common.h:37: fatal error: config.h: No such file or directory compilation terminated. make: *** [include/autoconf.mk.dep] Error 1 While going through the files in u-boot I made the following observations: The config.mk available in the TOPDIR of the u-boot folder has the following variable definition: gccincdir := $(shell $(CC) -print-file-name=include) CPPFLAGS += -I$(TOPDIR)/include CPPFLAGS += -fno-builtin -ffreestanding -nostdinc \ -isystem $(gccincdir) -pipe $(PLATFORM_CPPFLAGS) Where $(TOPDIR)/include = /u-boot-2010.09-rc2/include (AND) $(gccincdir) = is the cross compiler's include library, which in my case is, c:/cygwin/home/e458110/linuxproj/tools/bin/../lib/gcc/arm-none-linux-gnu eabi/4.4.1/include >From what I can understand from this, the -I flag makes the u-boot /INCLUDE directory to be the first in list to search for header files while preprocessing and -isystem flag asks the compiler to consider the cross compiler's as the system directory or search for system headers. Now I went make to common.h file which is throwing the error given above and observed that config.h is defined in angle brackets: i.e. #include <config.h> So what I feel is happening here is that the compiler only searches its own include directory for headers since the files are in < > brackets. When I copy all the files in the uboot /include directory to the compiler's include the build process starts while fails at some point since some autogenerated header files are created in the u-boot/include by default and needs to be moved to the compiler's include each time proceed. I could go about changing the #include <config.h> to #include "config.h" but this is going to be very tedious and time consuming as the entire u-boot code needs to be changed for this. I tried various combinations of gcc flags for the variable CPPFLAGS, all failed for reasons which I was able to trace back. Has this condition been observed before and is there any work around for it? Also, please correct me if my understanding is wrong. I am at crucial point in my project would be delighted to have support at the earliest. Regards, Shyama

1 0

[U-Boot] Question/proposal: why dts files are not normally accepted into u-boot repo?
by Alex Dubov 30 Dec '10

30 Dec '10

Greetings. In the old times it was customary to tweak the linux kernel for each and every board, creating "named" configurations, so naturally dts files ended up in the kernel source tree. Yet, kernel build system does nothing with those files. Moreover, during initial board development, u-boot board config header is written first and the dts file follows, based on the header information. It seems it would be wise to accept .dts files together with the rest of the board specific sources into the u-boot tree. The space required is not large and the resulting arrangement will be considerably more convenient for old and new board development.

1 0

[U-Boot] [PATCH] DaVinci: Remove incorrect CONFIG option
by s-paulraj＠ti.com 29 Dec '10

29 Dec '10

From: Sandeep Paulraj <s-paulraj(a)ti.com> The option CONFIG_SOC_DM6447 seems to have ended up in the code by mistake. It is not used anywhere and there is no chip called DM6447. Signed-off-by: Sandeep Paulraj <s-paulraj(a)ti.com> --- arch/arm/cpu/arm926ejs/davinci/cpu.c | 6 ------ 1 files changed, 0 insertions(+), 6 deletions(-) diff --git a/arch/arm/cpu/arm926ejs/davinci/cpu.c b/arch/arm/cpu/arm926ejs/davinci/cpu.c index 340c5be..8b57205 100644 --- a/arch/arm/cpu/arm926ejs/davinci/cpu.c +++ b/arch/arm/cpu/arm926ejs/davinci/cpu.c @@ -54,12 +54,6 @@ #define DDR_PLLDIV PLLC_PLLDIV2 #endif -#ifdef CONFIG_SOC_DM6447 -#define ARM_PLLDIV PLLC_PLLDIV2 -#define DSP_PLLDIV PLLC_PLLDIV1 -#define DDR_PLLDIV PLLC_PLLDIV1 -#endif - #ifdef CONFIG_SOC_DM646X #define DSP_PLLDIV PLLC_PLLDIV1 #define ARM_PLLDIV PLLC_PLLDIV2 -- 1.6.0.4

1 0