December 2010 - U-Boot

Re: [U-Boot] NEC OHCI chip bug
by Martin Mueller 21 Dec '10

21 Dec '10

Hi Gavin, > > detection might work without PCI slave-initiated transfer and the > > root hub is OHCI internal. But - just guessing. If you have double > > checked the window there are no more ideas from my side. > > Do you setup host bridge window base & size? Exactly, I didn¡¦t set > it before. Suppose, PCI devices on bus 0 should work, right ? yes, usually at least size is set in a register. The documentation of your (PCI) hardware can be a valuable source of information here. Regards, Martin

2 1

[U-Boot] Please Pull u-boot-ti/next
by s-paulraj＠ti.com 21 Dec '10

21 Dec '10

Wolfgang, Please pull u-boot-ti/next The DaVinci MMC/SD patches were acked by Andy long ago but never made it to any tree. Please look at http://www.mail-archive.com/u-boot@lists.denx.de/msg32375.html I am trying to upstream the patches as the original author seems busy Regards, Sandeep The following changes since commit b8339e2b9f32663411dba0f48e25b23f542d53bc: Matthew McClintock (1): p1022ds: enable reginfo command are available in the git repository at: git://git.denx.de/u-boot-ti.git next Mike Rapoport (1): OMAP3: add CM-T35 board Sandeep Paulraj (3): Davinci MMCSD Support DaVinci DM355: Adding MMC/SD support for DM355 EVM DaVinci DM365: Adding MMC/SD support for DM365 EVM MAINTAINERS | 4 + arch/arm/include/asm/arch-davinci/sdmmc_defs.h | 175 ++++++++++ board/cm_t35/Makefile | 47 +++ board/cm_t35/cm_t35.c | 371 ++++++++++++++++++++++ board/davinci/dm355evm/dm355evm.c | 41 +++ board/davinci/dm365evm/dm365evm.c | 49 +++ boards.cfg | 1 + doc/README.omap3 | 16 +- drivers/mmc/Makefile | 1 + drivers/mmc/davinci_mmc.c | 404 ++++++++++++++++++++++++ include/configs/cm_t35.h | 352 +++++++++++++++++++++ include/configs/davinci_dm355evm.h | 22 ++ include/configs/davinci_dm365evm.h | 22 ++ include/mmc.h | 3 + 14 files changed, 1506 insertions(+), 2 deletions(-) create mode 100644 arch/arm/include/asm/arch-davinci/sdmmc_defs.h create mode 100644 board/cm_t35/Makefile create mode 100644 board/cm_t35/cm_t35.c create mode 100644 drivers/mmc/davinci_mmc.c create mode 100644 include/configs/cm_t35.h

1 0

[U-Boot] eNET build fails with "invalid application of 'sizeof' to incomplete type 'struct global_data'"
by Loïc Minier 20 Dec '10

20 Dec '10

Hey There is now a u-boot package in Debian and Ubuntu and it fails to build the i386 eNET board with: gcc -DDO_DEPS_ONLY \ -g -Os -ffunction-sections -fvisibility=hidden -D__KERNEL__ -DCONFIG_SYS_TEXT_BASE=0x06000000 -I/build/buildd-u-boot_2010.12~rc3-1-i386-qoDl82/u-boot-2010.12~rc3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/lib/gcc/i486-linux-gnu/4.4.5/include -pipe -fno-strict-aliasing -Wstrict-prototypes -mregparm=3 -fomit-frame-pointer -ffreestanding -fno-toplevel-reorder -fno-stack-protector -mpreferred-stack-boundary=2 -DCONFIG_I386 -D__I386__ -march=i386 -Werror -fno-dwarf2-cfi-asm -Wall -Wstrict-prototypes -fno-stack-protector \ -o lib/asm-offsets.s lib/asm-offsets.c -c -S lib/asm-offsets.c: In function 'main': lib/asm-offsets.c:25: error: invalid application of 'sizeof' to incomplete type 'struct global_data' The build proceeds much further if I replace sizeof(struct global_data) with sizeof(gd_t) in lib/asm-offsets.c. I'm not sure which way this should be fixed: * add struct global_data to arches which only have gd_t * use sizeof(gd_t) in lib/asm-offsets.c instead of sizeof(struct global_data) -- Loïc Minier

2 1

[U-Boot] SUNITA
by sunita acha 20 Dec '10

20 Dec '10

Hello my dear, How are you today, i hope that you are fine, please dont be offended is my great pleasure to reach you, My name is Miss Sunita,i saw your contact today at(www.mybloglog.com) that made me to contact you, please i will like you to reply me because i have an importan message to you, Despite that we have not seen in person, i will reply you with my pictures for you to know me and more about me on my next mail, remember apply its a great opportunity,waiting to hear from you,

1 0

[U-Boot] Adding a new board to U-Boot
by Robert Mortimer 20 Dec '10

20 Dec '10

First off I aplogise for top posting. It is common on some of the groups I am in You will be glad to know I have registerd our board with the ARM registry I have updated my local git repo to reflect the number we were given. None of the porting guides I found round the internet seemed to include this step Please could you confirm my understanding that the unique reference is passed to the loading Linux kernel to allow it to configure it's self for the target hardware. Regards Rob Blue Chip Technology Limited. Chowley Oak Lane, Tattenhall, Chester, Cheshire CH3 9EX Tel: 01829 772000 Registered in England 3110403 Vat No: GB 618 374134

2 1

[U-Boot] Board Porting MACH_TYPE question
by Robert Mortimer 20 Dec '10

20 Dec '10

Hi, I am porting a board similar to the Beagle to U-Boot. The Beagle config works but needs further pin MUXing . I have copied the Beagle board config to a new name and when compiled the binary performs as per the Beale one. My issue is when I change the line 51: gd->bd->bi_arch_number = MACH_TYPE_OMAP3_BEAGLE; in the copy of beagle.h (now re2v2.h) to 51: gd->bd->bi_arch_number = MACH_TYPE_OMAP3_RE2V2; The loader now unpacks the loaded kernel and then halts at the stage where it tries to boot it I have updated arch/arm/include/ asm /mach-types.h and include/ asm /mach-types.h. If I grep for the relevant changes/ additions I get the following:- grep -r machine_is_omap3_beagle * arch/arm/include/ asm /mach-types.h:# define machine_is_omap3_beagle() (machine_arch_type == MACH_TYPE_OMAP3_BEAGLE) arch/arm/include/ asm /mach-types.h:# define machine_is_omap3_beagle() (0) include/ asm /mach-types.h:# define machine_is_omap3_beagle() (machine_arch_type == MACH_TYPE_OMAP3_BEAGLE) include/ asm /mach-types.h:# define machine_is_omap3_beagle() (0) grep -r machine_is_omap3_re2v2 * arch/arm/include/ asm /mach-types.h:# define machine_is_omap3_re2v2() (machine_arch_type == MACH_TYPE_OMAP3_RE2V2) arch/arm/include/ asm /mach-types.h:# define machine_is_omap3_re2v2() (0) include/ asm /mach-types.h:# define machine_is_omap3_re2v2() (machine_arch_type == MACH_TYPE_OMAP3_RE2V2) include/ asm /mach-types.h:# define machine_is_omap3_re2v2() (0) grep -r machine_is_omap3_beagle * arch/arm/include/ asm /mach-types.h:# define machine_is_omap3_beagle() (machine_arch_type == MACH_TYPE_OMAP3_BEAGLE) arch/arm/include/ asm /mach-types.h:# define machine_is_omap3_beagle() (0) include/ asm /mach-types.h:# define machine_is_omap3_beagle() (machine_arch_type == MACH_TYPE_OMAP3_BEAGLE) include/ asm /mach-types.h:# define machine_is_omap3_beagle() (0) grep -r machine_is_omap3_re2v2 * arch/arm/include/ asm /mach-types.h:# define machine_is_omap3_re2v2() (machine_arch_type == MACH_TYPE_OMAP3_RE2V2) arch/arm/include/ asm /mach-types.h:# define machine_is_omap3_re2v2() (0) include/ asm /mach-types.h:# define machine_is_omap3_re2v2() (machine_arch_type == MACH_TYPE_OMAP3_RE2V2) include/ asm /mach-types.h:# define machine_is_omap3_re2v2() (0) I have defined MACH_TYPE_OMAP3_RE2V2 in arch/arm/include/ asm /mach-types.h and given it the next number I can't see where machine_arch_type is used outside of board configuration I can't see where 1546 (the Beagle number) is used either Any idea what additional work needs to be done to move to MACH_TYPE_OMAP3_RE2V2 from MACH_TYPE_OMAP3_BEAGLE? Regards Rob Blue Chip Technology Limited. Chowley Oak Lane, Tattenhall, Chester, Cheshire CH3 9EX Tel: 01829 772000 Registered in England 3110403 Vat No: GB 618 374134

2 1

Re: [U-Boot] TFTP Issue
by T K, Sunil Kumar 20 Dec '10

20 Dec '10

I use tftpboot <load_address> <image> Can you please let me know what are the other options and their syntax for loading a image? -----Original Message----- From: sywang [mailto:sywang@dongniannetworks.com] Sent: Friday, December 17, 2010 11:51 AM To: T K, Sunil Kumar; u-boot(a)lists.denx.de Subject: RE: [U-Boot] TFTP Issue Do you have bootp or DHCP server? -----Original Message----- From: u-boot-bounces(a)lists.denx.de [mailto:u-boot-bounces@lists.denx.de] On Behalf Of T K, Sunil Kumar Sent: 2010年12月17日 14:14 To: 'u-boot(a)lists.denx.de' Subject: [U-Boot] TFTP Issue Hi All, When I start for TFTP I see below shown messages on my screen though I had set serverip properly. Can anyone please comment on the issue. ===================================== Retry count exceeded; starting again BOOTP broadcast 1 BOOTP broadcast 2 BOOTP broadcast 3 BOOTP broadcast 4 BOOTP broadcast 5 ===================================== Thanks in advance! Best Regards, Sunil

2 7

[U-Boot] [PATCH 1/1] armv7: start.S: code cleanup
by Jason Liu 20 Dec '10

20 Dec '10

Remove the useless code from start.S Signed-off-by: Jason Liu <r64343(a)freescale.com> --- arch/arm/cpu/armv7/start.S | 2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S index 684f2d2..cb4f92f 100644 --- a/arch/arm/cpu/armv7/start.S +++ b/arch/arm/cpu/armv7/start.S @@ -171,7 +171,6 @@ stack_setup: beq clear_bss /* skip relocation */ #endif mov r1, r6 /* r1 <- scratch for copy_loop */ - ldr r2, _TEXT_BASE ldr r3, _bss_start_ofs add r2, r0, r3 /* r2 <- source end address */ @@ -224,7 +223,6 @@ fixnext: clear_bss: ldr r0, _bss_start_ofs ldr r1, _bss_end_ofs - ldr r3, _TEXT_BASE /* Text base */ mov r4, r6 /* reloc addr */ add r0, r0, r4 add r1, r1, r4 -- 1.7.0.4

3 2

[U-Boot] Amazing End of Year Investment
by Felipe Sifuentes Ruiz 20 Dec '10

20 Dec '10

1 0

[U-Boot] Unwritable registers on MPC8308
by Guy Morand 20 Dec '10

20 Dec '10

Hello, I'm working on a board based on MPC8308 and trying to configure the RTC. The problem is that when I try to write into these registers, their value is always 0x0 !!! I've tried a lot of things such as debugging step by step with gdb/JTAG/Peedi, writing to these registers with the Peedi, desabling address translation, using writel/out_le32/..., they are always 0x0 ! However, writing in RAM works perfectly ! Here is a sample of code about what I'd like to do : --------------------------------------- #define RTC_BASE CONFIG_SYS_IMMR + 0x300 #define RTC_CNR RTC_BASE #define RTC_LDR RTC_BASE + 0x4 #define RTC_PSR RTC_BASE + 0x8 #define RTC_TR RTC_BASE + 0xC #define RTC_EVR RTC_BASE + 0x10 #define RTC_ALR RTC_BASE + 0x14 void initRTC() { u32* volatile psr = RTC_PSR; u32* volatile ldr = RTC_LDR; u32* volatile cnr = RTC_CNR; u32* volatile loadaddr = 0x800000; u32 psr_value = 0x0; u32 ldr_value = 0xABCD1234; u32 cnr_value = (0x1 << 7);// | (1 << 24); u32 loadValue = 0xBEEFABCD; *psr = psr_value; // Divide clock by 1 *ldr = ldr_value; // Initial time *cnr = cnr_value;// | (1 << 24);// Clock enable use, CSB clock *loadaddr = loadValue; printf("PSR pointer is 0x%08X, put 0x%08X and actually is 0x%08X\n", psr, psr_value, *psr); printf("LDR pointer is 0x%08X, put 0x%08X and actually is 0x%08X\n", ldr, ldr_value, *ldr); printf("CNR pointer is 0x%08X, put 0x%08X and actually is 0x%08X\n", cnr, cnr_value, *cnr); printf("loadaddr pointer is 0x%08X, put 0x%08X and actually is 0x%08X\n", loadaddr, loadValue, *loadaddr); } --------------------------------------- And the output : --------------------------------------- PSR pointer is 0xE0000308, put 0x00000000 and actually is 0x00000000 LDR pointer is 0xE0000304, put 0xABCD1234 and actually is 0x00000000 CNR pointer is 0xE0000300, put 0x00000080 and actually is 0x00000000 loadaddr pointer is 0x00800000, put 0xBEEFABCD and actually is 0xBEEFABCD --------------------------------------- I have the same problem with ANY register ! I also noticed a register that should be initialized to 0xFFFFFFFF is actually 0x0 at reset ! More it goes, more I think I'm reading the wrong datasheet or the wrong number has been printed on the chip :-p ! Or a bug ... what I doubt ... ! I've been stuck here all the week, without finding any clue, please give me something to dig into ! Thanks for your precious advices ! Guy Morand

2 3