March 2006 - U-Boot

[U-Boot-Users] Re: compile u-boot with recent toolchain : symbols problem
by Anton Wöllert 22 Mar '06

22 Mar '06

I've got the same problem with binutils 2.16 and gcc 3.4.4. also binutils 2.16.91.0.1 doesn't work right. > > > > I used to compile U-Boot with ELDK, but I currently need to work with > > newer toolchain : > > - binutils-2.16 > > - gcc-3.4.3 > > This looks line a binutils problem, then. May I ask why you have to > use binutils-2.16 ? May I ask you why it should not be used? How to recover bugs, if people just use older software? > > And which exact board are we talking about? > > > The "__u_boot_cmd_start" symbol value, generated with this new > > toolchain, is wrong (U-Boot crashes when relocating the command > > table). > > Can you please provide exact data, like the differences between the > System.map and the u-boot.map files when using binutils-2.16 and > another, working version of binutils? [Please use the _same_ version > of GCC for this comparison.] > > > There are two new sections between "__u_boot_cmd_start" and > > ".u_boot_cmd" address : > > - .data.rel.local > > - .data.rel > > Can you please show exactly what happens? The above, i couldn't acknowledge, but u-boot definitly hangs _after_ relocating to memory. it will dump 'Now running in RAM at .....'. But then it hangs. After relocating, it tries to manually relocate the command table. But that doesn't work. Don't know why, but with the patch it works. Obviously __u_boot_cmd_start = .; .u_boot_cmd : { *(.u_boot_cmd) } __u_boot_cmd_end = .; and __u_boot_cmd_start = ADDR(.u_boot_cmd); .u_boot_cmd : { *(.u_boot_cmd) } __u_boot_cmd_end = .; should be the same. However, this should be a binutils bug or the linker script voodoo that is done with the first script above isn't really valid. Maybe .u_boot_cmd gets misalligned. Maybe i should try to DEBUG(& __u_boot_cmd_start) in both (the patched and unpatched) versions to see, where it points, or maybe objdump show more. Btw. this happens on the tqm8xx board. Thanks to Vincent for recovering that, that saved me a lot of time... kind regards Anton Wöllert

4 10

[U-Boot-Users] [QUESTION/PATCH] Does MPC8349EMDS_config supersede MPC8349ADS_config?
by KRONSTORFER Horst 22 Mar '06

22 Mar '06

hi kumar! in case MPC8349ADS_config will not be made obsolete in the near future the following patch (which may be applied against top of boot/u-boot/u-boot.git) makes sense. -h Signed-off-by: Horst Kronstorfer <hkronsto(a)frequentis.com> CHANGELOG * Fixed signature when calling spd_sdram() in board/mpc8349ads/mpc8349ads.c. board/mpc8349ads/mpc8349ads.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/board/mpc8349ads/mpc8349ads.c b/board/mpc8349ads/mpc8349ads.c index 505acbc..9841298 100644 --- a/board/mpc8349ads/mpc8349ads.c +++ b/board/mpc8349ads/mpc8349ads.c @@ -64,7 +64,7 @@ long int initdram (int board_type) /* DDR SDRAM - Main SODIMM */ im->sysconf.ddrlaw[0].bar = CFG_DDR_BASE & LAWBAR_BAR; #if defined(CONFIG_SPD_EEPROM) - msize = spd_sdram(NULL); + msize = spd_sdram(); #else msize = fixed_sdram(); #endif

2 1

[U-Boot-Users] PATCH: Enable building on Mac OS X
by Jie Zhang 22 Mar '06

22 Mar '06

Hi, This patch will make u-boot build on Mac OS X. Yes. I saw the comments in tools/Makefile. But it does not compile on Mac OS X. It seems that the case the comment for is not true now. And fdatasync () is not available on darwin. I tested this patch on Mac OS X 10.4.5. Thanks, Jie

1 0

RE: [U-Boot-Users] 2 flash sizes, starting at different addresses in the same u-boot binary?
by Joao, Nuno (ext) 22 Mar '06

22 Mar '06

Do you know by heart the name of any of these systems? Thanks and Best Regards -----Original Message----- From: wd(a)denx.de [mailto:wd@denx.de] In message <E7E846FF4F1FE947AABFF850350820780CBFC4(a)PTLISI051MSX.PT001.SIEMENS.NET> you wrote: > > I needed to have u-boot support 2 versions of the same hardware, > in which the only difference is the flash size. I'm using the CFI > driver. If in both versions of the hardware the flash started at > the same address, the CFI driver would take care of it. However, > they don't start at the same address (they must end at the same > address). > Does anyone has a clue if there is an easy way to have u-boot > support these 2 versions in the same binary? U-Boot does this in a couple of systems. It's not difficult to support such a setup.

1 0

[U-Boot-Users] Cannot compile fw_env tools in u-boot-1.1.4
by antonio.dibacco 22 Mar '06

22 Mar '06

I go under u-boot-1.1.4/tools/env/ and try to do make but I receive the following error -> make ppc_8xx-gcc -Wall -DUSE_HOSTCC crc32.c fw_env.c fw_env_main.c -o fw_printenv In file included from fw_env.c:34: /opt/eldk_3.1.1/ppc_8xx/usr/include/linux/mtd/mtd.h:13:2: #error This is a kernel header. Perhaps include mtd-user.h instead? I tried to include mtd-user.h but there still a lot of errors!! Bye, Antonio.

2 2

RE: [U-Boot-Users] TQM866 SDRAM Table
by Joao, Nuno (ext) 22 Mar '06

22 Mar '06

Just for info, last time I saw, FreeScale had a Windows application to literaly draw the waveform. The application outputs a C structure with the values. Look in the website (start in the product's page), it was there. And please stop posting HTML messages in this mail list :)) Best Regards > I would like to know how to modify the table to introduce the modification suggested by Freescale.

2 1

[U-Boot-Users] 2 flash sizes, starting at different addresses in the same u-boot binary?
by Joao, Nuno (ext) 22 Mar '06

22 Mar '06

Hello, I needed to have u-boot support 2 versions of the same hardware, in which the only difference is the flash size. I'm using the CFI driver. If in both versions of the hardware the flash started at the same address, the CFI driver would take care of it. However, they don't start at the same address (they must end at the same address). Does anyone has a clue if there is an easy way to have u-boot support these 2 versions in the same binary? Thanks and Best Regards, Nuno João

2 1

[U-Boot-Users] TQM866 SDRAM Table
by SETTE AGOSTINO - technolabs 21 Mar '06

21 Mar '06

Hello, I am currently using a TQM866 with a cpu clock of 133MHz and I have problems with the configuration of the SDRAM. Here attached there is the sdram_table from the following file: /u-boot_1.0.0/board/siemens/CCM/ccm.c #define _NOT_USED_ 0xFFFFFFFF const uint sdram_table[] = { /* * Single Read. (Offset 0 in UPMA RAM) */ 0x1F0DFC04, 0xEFAFBC04, 0x1EAF7C04, 0xF1AFFC04, 0xEFBAFC00, 0x1FF5FC47, _NOT_USED_, _NOT_USED_, /* last */ /* * Burst Read. (Offset 8 in UPMA RAM) */ 0x1F0DFC04, 0xEFAFBC04, 0x1EAF7C04, 0xF0AFFC04, 0xF0AFFC00, 0xF0AFFC00, 0xF1AFFC00, 0xEFBAFC00, /* last */ 0x1FF5FC47, _NOT_USED_, _NOT_USED_, _NOT_USED_, _NOT_USED_, _NOT_USED_, _NOT_USED_, _NOT_USED_, /* * Single Write. (Offset 18 in UPMA RAM) */ 0x1F0DFC04, 0xEEABBC00, 0x01B27C04, 0xFFFFFC04, 0x1FF5FC47, _NOT_USED_, _NOT_USED_, _NOT_USED_, /* last */ /* * Burst Write. (Offset 20 in UPMA RAM) */ 0x1F0DFC04, 0xEEABBC00, 0x10A77C00, 0xF0AFFC00, 0xF0AFFC00, 0xE1BAFC04, 0xFFFFFC04, 0x1FF5FC47, /* last */ _NOT_USED_, _NOT_USED_, _NOT_USED_, _NOT_USED_, /* * SDRAM Initialization (offset 2C in UPMA RAM) * * This is no UPM entry point. The following definition uses * the remaining space to establish an initialization * sequence, which is executed by a RUN command. * */ 0x1FF5FC34, 0xEFEABC34, 0x1FB57C35, _NOT_USED_, /* last */ /* * Refresh (Offset 30 in UPMA RAM) */ 0x1FFD7C84, 0xFFFFFC04, 0xFFFFFC04, 0xFFFFFC04, 0xFFFFFC84, 0xFFFFFC07, _NOT_USED_, _NOT_USED_, /* last */ _NOT_USED_, _NOT_USED_, _NOT_USED_, _NOT_USED_, /* * Exception. (Offset 3c in UPMA RAM) */ 0xFFFFFC07, _NOT_USED_, _NOT_USED_, _NOT_USED_, /* last */ }; We have only the following custom connections: RAS --> GPL2 A10 --> GPL0 CAS --> GPL3 WE --> GPL1 Freescale said that the SDRAM timing is determined by patterns programmed by the user in the UPM (User Programmable Machine). According to the SDRAM manufacturers specification the "Write Recovery Time" tWR is 15ns minimum. In the current UPM patterns they see only one clock period for tWR. The clock period can be determined as follows: This also explains why the board works ok when the core frequency is reduced to 130MHz, since this translates to a bus clock period of 15.38ns. They asked to insert another clock period in the UPM pattern for "Write Recovery Time". I would like to know how to modify the table to introduce the modification suggested by Freescale. Thanks in advance for you support Agostino Sette

2 1

[U-Boot-Users] Regarding OHCI support in U-boot
by R Arun Kumar 21 Mar '06

21 Mar '06

Hello Sir I am trying to port usb_ohci code (u-boot-1.1.3 version) from cpu/arm920t/s3c24x0 to our chip NEC 720101 chip and it is found that it is hanging when we run usb tree call, even though we havnot out any usb devices. Please help us. ATS1.0> usb start (Re)start USB... USB: scanning bus for devices... 1 USB Devices found ATS1.0> usb info 1: Hub, USB Revision 1.10 - OHCI Root Hub - Class: Hub - PacketSize: 8 Configurations: 1 - Vendor: 0x0000 Product 0x0000 Version 0.0 Configuration: 1 - Interfaces: 1 Self Powered 0mA Interface: 0 - Alternate Settings 0, Endpoints: 1 - Class Hub - Endpoint 1 In Interrupt MaxPacket 2 Interval 255ms ATS1.0> usb tree Device Tree: 1 Hub (12MBit/s, 0mA) | OHCI Root Hub | | Regards R Arun Kumar Sr.Project Engineer RASS IT Solutions (P) Ltd.

2 1

[U-Boot-Users] [PATCH] Make blackfin configuration pass compilation with the current toolchain
by Aubrey 21 Mar '06

21 Mar '06

Hi Wolfgang, It's great the Richard's blackfin patch has been applied. But the patch it's really old and has some obsolete codes. So I made a patch against the current git repository. After applied the patch, the uboot can be compiled and work properly on the BF533 STAMP/EZKIT board. The patch is based on following commit ID in the current U-boot git repository. ============================================================ commit ff7fefe6797246b2748530f965f2e41de34a982a Author: Wolfgang Denk <wd(a)pollux.denx.de> Date: Mon Mar 13 12:37:35 2006 +0100 Apply SoC concept to arm926ejs CPUs, i.e. move the SoC specific timer and cpu_reset code from cpu/$(CPU) into the new cpu/$(CPU)/$(SOC) directories Patch by Andreas Engel, 13 Mar 2006 ============================================================ Changelog entry: * Make blackfin pass compilation with the current toolchain. Patch by Aubrey.Li <aubrey.li(a)analog.com> Thanks, -Aubrey

1 1