October 2004 - U-Boot

[U-Boot-Users] initrd on MIPS
by Thomas Lange 07 Oct '04

07 Oct '04

I have been testing initrd for my dbAu1000 board. It seems that my kernel ( 2.4.25 ) expects the start address of the initrd to be given as a cached sdram address. If this is true for all mips boards, I will prepare a patch for lib_mips/mips_linux.c Any objections? /T

2 1

[U-Boot-Users] Porting U-boot
by calvin 07 Oct '04

07 Oct '04

I am trying to port U-boot to a board which uses Galileo(GT64120) system controller to access SDRAM. does any of the boards supported by U-boot have a similar interface ? Thanks and Regards, Pooja

1 0

[U-Boot-Users] Debugging in u-boot
by MuthuGanesh M 07 Oct '04

07 Oct '04

Hi , I am working with MPC885 processor. I am using BDI2000 for debugging. I can able to debug u-boot by stepping. Using gdb i loaded new symbol file(in ram address) and i am now in a position to debug in ram. I am having my own commands for my custom board, i want to debug the functions, called by the commands. So if i issue a break point, i cannot break at the function call. Once i give breakpoints, the line number and file names coming in gdb prompt are fine. But it is not hitting the break point. BDI config files are OK. My procedure is as per the manual (DULG/Manual). Can anybody help me in solving this Regards, Muthu ganesh.M

1 0

[U-Boot-Users] sc520 problems with objcopy
by Aras Vaichas 07 Oct '04

07 Oct '04

I've been porting to an sc520 based board and I've had several compiler and linker issues which I think I have solved. The problem now is that objcopy never finishes and uses all available memory. I have to kill the process otherwise it starts to try and use all virtual memory as well. I did a system call trace, and from it you can see that it gets to a point where it is calling brk() and from this it never seems to end. Has anyone else had this problem? Is it a problem caused by linker/compiler settings? Any clues would be appreciated! root@gentoo u-boot-1.1.1 # make ... SNIP ... UNDEF_SYM=`objdump -x lib_generic/libgeneric.a board/sc520_dsb/libsc520_dsb.a cpu/i386/libi386.a lib_i386/libi386.a fs/cramfs/libcramfs.a fs/fat/libfat.a fs/fdos/libfdos.a fs/jffs2/libjffs2.a fs/reiserfs/libreiserfs.a net/libnet.a disk/libdisk.a rtc/librtc.a dtt/libdtt.a drivers/libdrivers.a drivers/sk98lin/libsk98lin.a post/libpost.a post/cpu/libcpu.a common/libcommon.a |sed -n -e 's/.*$__u_boot_cmd_.*$/-u\1/p'|sort|uniq`;\ ld -Bstatic -T /samba/development/40_Magellan_Standard_Software/MAL/boot/u-boot-1.1.1/board/sc520_dsb/u-boot.lds -Ttext 0x387c0000 $UNDEF_SYM cpu/i386/start.o cpu/i386/start16.o cpu/i386/reset.o \ --start-group lib_generic/libgeneric.a board/sc520_dsb/libsc520_dsb.a cpu/i386/libi386.a lib_i386/libi386.a fs/cramfs/libcramfs.a fs/fat/libfat.a fs/fdos/libfdos.a fs/jffs2/libjffs2.a fs/reiserfs/libreiserfs.a net/libnet.a disk/libdisk.artc/librtc.a dtt/libdtt.a drivers/libdrivers.a drivers/sk98lin/libsk98lin.a post/libpost.a post/cpu/libcpu.a common/libcommon.a --no-warn-mismatch -L /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4 -lgcc --end-group \ -Map u-boot.map -o u-boot objcopy --gap-fill=0xff -O srec u-boot u-boot.srec ... I press CTRL+C at this point to interrupt, otherwise all my memory gets used. make: *** [u-boot.srec] Interrupt root@gentoo u-boot-1.1.1 # objcopy --version GNU objcopy 2.14.90.0.8 20040114 root@gentoo u-boot-1.1.1 # ll u-boot -rwxrwxr-x 1 root root 594727 Oct 6 12:04 u-boot ... I perform a system call trace here to see what is happening during objcopy root@gentoo u-boot-1.1.1 # strace objcopy --gap-fill=0xff -O srec u-boot u-boot.srec execve("/usr/bin/objcopy", ["objcopy", "--gap-fill=0xff", "-O", "srec", "u-boot", "u-boot.srec"], [/* 52 vars */]) = 0 uname({sys="Linux", node="gentoo", ...}) = 0 brk(0) = 0x808b000 open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory) mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40014000 open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=76539, ...}) = 0 mmap2(NULL, 76539, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40015000 close(3) = 0 open("/usr/lib/libbfd-2.14.90.0.8.so", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200\370"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=618708, ...}) = 0 mmap2(NULL, 634196, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40028000 mmap2(0x400b8000, 28672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x8f) = 0x400b8000 mmap2(0x400bf000, 15700, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x400bf000 close(3) = 0 open("/lib/libdl.so.2", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p\34\0\000"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=10964, ...}) = 0 mmap2(NULL, 8624, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x400c3000 mmap2(0x400c5000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x2) = 0x400c5000 close(3) = 0 open("/lib/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200Y\1"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=1174424, ...}) = 0 mmap2(NULL, 1104676, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x400c6000 mmap2(0x401ce000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x107) = 0x401ce000 mmap2(0x401d2000, 6948, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x401d2000 close(3) = 0 munmap(0x40015000, 76539) = 0 open("/dev/urandom", O_RDONLY) = 3 read(3, "\316\324\316\262", 4) = 4 close(3) = 0 brk(0) = 0x808b000 brk(0x80ac000) = 0x80ac000 brk(0) = 0x80ac000 brk(0) = 0x80ac000 stat64("u-boot", {st_mode=S_IFREG|0775, st_size=594727, ...}) = 0 stat64("u-boot", {st_mode=S_IFREG|0775, st_size=594727, ...}) = 0 open("u-boot", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0775, st_size=594727, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40015000 _llseek(3, 0, [0], SEEK_SET) = 0 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0\3\0\1\0\0\0\0\0|84"..., 4096) = 4096 _llseek(3, 4096, [4096], SEEK_SET) = 0 _llseek(3, 4096, [4096], SEEK_SET) = 0 _llseek(3, 4096, [4096], SEEK_SET) = 0 _llseek(3, 4096, [4096], SEEK_SET) = 0 _llseek(3, 4096, [4096], SEEK_SET) = 0 _llseek(3, 4096, [4096], SEEK_SET) = 0 _llseek(3, 4096, [4096], SEEK_SET) = 0 _llseek(3, 4096, [4096], SEEK_SET) = 0 _llseek(3, 4096, [4096], SEEK_SET) = 0 _llseek(3, 4096, [4096], SEEK_SET) = 0 _llseek(3, 4096, [4096], SEEK_SET) = 0 _llseek(3, 4096, [4096], SEEK_SET) = 0 _llseek(3, 557056, [557056], SEEK_SET) = 0 read(3, "entoo Linux 3.3.4-r1, ssp-3.3.2-"..., 4096) = 4096 _llseek(3, 561152, [561152], SEEK_SET) = 0 _llseek(3, 0, [0], SEEK_SET) = 0 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0\3\0\1\0\0\0\0\0|84"..., 4096) = 4096 stat64("u-boot.srec", {st_mode=S_IFREG|0664, st_size=0, ...}) = 0 open("u-boot.srec", O_RDWR|O_CREAT|O_TRUNC, 0666) = 4 _llseek(3, 557056, [557056], SEEK_SET) = 0 read(3, "entoo Linux 3.3.4-r1, ssp-3.3.2-"..., 4096) = 4096 read(3, "\0\0\0\0\0\0\361\377=\5\0\0 \360\376\377\0\0\0\0\0\0\361"..., 16384) = 16384 read(3, "\n\0\0\0\22\0\1\0\3;\0\0\324\214|8\372\0\0\0\22\0\1\0\v"..., 4096) = 4096 brk(0) = 0x80ac000 brk(0x80db000) = 0x80db000 read(3, "urge_tx_ring\0rx_next\0rx_ring\0tx_"..., 12288) = 12288 read(3, "\0__u_boot_cmd_cp\0strspn\0NetSendP"..., 4096) = 807 _llseek(3, 8192, [8192], SEEK_SET) = 0 read(3, "\270\30\0\0\0\216\340\216\330\216\350\216\300\216\320\275"..., 81920) = 81920 read(3, "\311\351\t\371\377\377\215e\364[^_\311\303U\211\345WVS"..., 4096) = 4096 brk(0) = 0x80db000 brk(0x8103000) = 0x8103000 _llseek(3, 94208, [94208], SEEK_SET) = 0 read(3, "Redirect to \0*** ERROR: `serveri"..., 16384) = 16384 read(3, "h() routine too large (%d) %p - "..., 4096) = 4096 _llseek(3, 114688, [114688], SEEK_SET) = 0 read(3, "\0\0|8\0\0\2008\313\232}8\0\0@\0\223\f\0\0\224\f@\0\314"..., 4096) = 4096 _llseek(3, 4096, [4096], SEEK_SET) = 0 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 4096 _llseek(3, 118784, [118784], SEEK_SET) = 0 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 4096 _llseek(3, 122880, [122880], SEEK_SET) = 0 read(3, "\272\374\377f\270\313\360\r\200f\357\270\0\337\216\330"..., 4096) = 4096 _llseek(3, 126976, [126976], SEEK_SET) = 0 _llseek(3, 126976, [126976], SEEK_SET) = 0 read(3, "\1\0\0\0\0\0\260\3\\\3\0\0\1\0\0\0d\0\0\0\0\0|8\22\0\0"..., 8192) = 8192 read(3, "\275\1\0\0\0\0\0\0D\0`\1\301\1\0\0\0\0\0\0D\0a\1\304\1"..., 4096) = 4096 read(3, "!\0I\23/\v\0\0\t\17\0\v\vI\23\0\0\n\25\1\1\23\'\f\0\0\v"..., 28672) = 28672 read(3, "8\n\0\0\16\26\0\3\10:\v;\vI\23\0\0\17\23\1\1\23\3\16\v"..., 4096) = 4096 mmap2(NULL, 286720, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x401d4000 read(3, "Tu\7\0\0\0214\10\0\0\f\n\v1\6\307*\0\0\v!F\4\0\0\2#\0\6"..., 278528) = 278528 read(3, "\207\2\0\0\3#\264\4\5\327O\0\0\2@\207\2\0\0\3#\200\5\005"..., 4096) = 4096 munmap(0x401d4000, 286720) = 0 read(3, "\34V\325)I,V2V\10\36r\253p\234\200\342\343\272\236\3\t"..., 45056) = 45056 read(3, "\270b7;\270\3\274\1c/\3\v\267\3uc\3\f9da\3u9\3\f9:\3\346"..., 4096) = 4096 _llseek(3, 503808, [503808], SEEK_SET) = 0 read(3, "A\16\10\205\2B\r\5 \0\0\0\270\f\0\0\341=|8\227\0\0\0A\16"..., 16384) = 16384 read(3, "\2B\r\5F\203\5\206\4\207\3].\10\0\0\34\0\0\0\264M\0\0\324"..., 4096) = 4096 read(3, "\0__u_boot_cmd_chpart\0\0\0\0\0\256\1\0\0\2\0\331"..., 4096) = 4096 read(3, "\0\0flash_info\0\0\0\0\0p\0\0\0\2\0#>\3\0\207\17\0\0\217"..., 4096) = 4096 read(3, "\0\0p\0\0\0\206\0\0\0\0\0\0\0\0\0\0\0\301\0\0\0\315\0\0"..., 4096) = 4096 read(3, "ArpWaitPacketMAC\0NetOurHostName\0"..., 16384) = 16384 read(3, "pos\0data_in\0rtime_decompress\0com"..., 4096) = 4096 read(3, "entoo Linux 3.3.4-r1, ssp-3.3.2-"..., 4096) = 4096 brk(0) = 0x8103000 brk(0x8125000) = 0x8125000 brk(0) = 0x8125000 brk(0x8147000) = 0x8147000 brk(0) = 0x8147000 ... never ends ... regards, Aras Vaichas

1 1

[U-Boot-Users] (no subject)
by Eren Gurses 06 Oct '04

06 Oct '04

1 0

[U-Boot-Users] Programming 28F640J3 flash on ARM Integrator CP gets timeout
by Shawn 06 Oct '04

06 Oct '04

Hi, I use the ported ARM Integrator CP board and modified the flash part to support the new flash chip Intel StrataFlash 28F640J3. When programming the Flash with a big chunk of data (hundreds of KB or MB), it very often gets timeout. I changed the timeout value to a big numer (10 times of the original value), but it didn't help. I don't see the issue is related to the software. What else will cause this problem? I printed the status when programming or erasing gets timeout. Sometimes it shows low programming voltage detected (SR.3 == 1). Any hints are appreciated. -Shawn.

1 0

[U-Boot-Users] problem with cfi_flash.c & AT91RM9200DK
by Morten 05 Oct '04

05 Oct '04

Hello ! I have exchanged the flash on my AT91RM9200DK with a AT49BV320C cfi flash, and done all needed mods to the config file, every thing seems ok except that it get the size of the flash incorectly. It sayes that it is a 16x16 4m, 71 sector cfi complient flash, when it should be a 2097 x 16, 32m, 71 sector flash ? Anyone have any tips for me on how to fix this ? protect / unprotect seems to work fine, and it even writes without complaining, but nothing actualy gets writen ! Debug: U-Boot 1.1.2 (Oct 4 2004 - 11:17:41) U-Boot code: 21F00000 -> 21F188E4 BSS: -> 21F1CFB4 RAM Configuration: Bank #0: 20000000 32 MB flash detect cfi fwc addr 10000000 cmd ff ff 8bit x 8 bit fwc addr 10000055 cmd 98 98 8bit x 8 bit is= cmd 51(Q) addr 10000010 is= ff 51 fwc addr 10000000 cmd ff ffff 16bit x 8 bit fwc addr 100000aa cmd 98 9898 16bit x 8 bit is= cmd 51(Q) addr 10000020 is= 0051 5151 fwc addr 10000000 cmd ff 00ff 16bit x 16 bit fwc addr 100000aa cmd 98 0098 16bit x 16 bit is= cmd 51(Q) addr 10000020 is= 0051 0051 is= cmd 52(R) addr 10000022 is= 0052 0052 is= cmd 59(Y) addr 10000024 is= 0059 0059 ushort addr is at 10000050 info->portwidth = 2 addr[0] = 0x1 addr[1] = 0x0 addr[2] = 0x0 addr[3] = 0x0 retval = 0x1 device interface is 1 found port 2 chip 2 port 16 bits chip 16 bits ushort addr is at 10000026 info->portwidth = 2 addr[0] = 0x3 addr[1] = 0x0 addr[2] = 0x0 addr[3] = 0x0 retval = 0x3 10000020 : 51 00 52 00 59 00 03 00 00 00 41 00 00 00 00 00 Q.R.Y.....A..... 10000030 : 00 00 00 00 00 00 27 00 36 00 b5 00 c5 00 04 00 ......'.6....... 10000040 : 00 00 0a 00 00 00 03 00 00 00 03 00 00 00 16 00 ................ 10000050 : 01 00 00 00 00 00 00 00 02 00 07 00 00 00 20 00 .............. . 10000060 : 00 00 3e 00 00 00 00 00 01 00 ff ff ff ff ff ff ..>............. 10000070 : ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ 10000080 : ff ff 50 00 52 00 49 00 31 00 30 00 86 00 01 00 ..P.R.I.1.0..... 10000090 : 00 00 00 00 80 00 03 00 03 00 ff ff ff ff ff ff ................ manufacturer is 3 size_ratio 1 port 16 bits chip 16 bits found 2 erase regions long addr is at 1000005a info->portwidth = 2 addr[0] = 0x7 addr[1] = 0x0 addr[2] = 0x0 addr[3] = 0x0 addr[4] = 0x20 addr[5] = 0x0 addr[6] = 0x0 addr[7] = 0x0 erase_region_count = 8 erase_region_size = 8192 long addr is at 10000062 info->portwidth = 2 addr[0] = 0x3e addr[1] = 0x0 addr[2] = 0x0 addr[3] = 0x0 addr[4] = 0x0 addr[5] = 0x0 addr[6] = 0x1 addr[7] = 0x0 erase_region_count = 63 erase_region_size = 65536 ushort addr is at 10000054 info->portwidth = 2 addr[0] = 0x0 addr[1] = 0x0 addr[2] = 0x0 addr[3] = 0x0 retval = 0x0 fwc addr 10000000 cmd ff 00ff 16bit x 16 bit Flash: 4 MB Bank # 1: CFI conformant FLASH (16 x 16) Size: 4 MB in 71 Sectors Erase timeout 8192 ms, write timeout 0 ms, buffer write timeout 1 ms, buffer size 1 Sector Start Addresses: 10000000 (RO) 10002000 (RO) 10004000 (RO) 10006000 (RO) 10008000 (RO) 1000A000 (RO) 1000C000 (RO) 1000E000 (RO) 10010000 (RO) 10020000 (RO) 10030000 (RO) 10040000 (RO) 10050000 (RO) 10060000 (RO) 10070000 (RO) 10080000 (RO) 10090000 (RO) 100A0000 (RO) 100B0000 (RO) 100C0000 (RO) 100D0000 (RO) 100E0000 (RO) 100F0000 (RO) 10100000 (RO) 10110000 (RO) 10120000 (RO) 10130000 (RO) 10140000 (RO) 10150000 (RO) 10160000 (RO) 10170000 (RO) 10180000 (RO) 10190000 (RO) 101A0000 (RO) 101B0000 (RO) 101C0000 (RO) 101D0000 (RO) 101E0000 (RO) 101F0000 (RO) 10200000 (RO) 10210000 (RO) 10220000 (RO) 10230000 (RO) 10240000 (RO) 10250000 (RO) 10260000 (RO) 10270000 (RO) 10280000 (RO) 10290000 (RO) 102A0000 (RO) 102B0000 (RO) 102C0000 (RO) 102D0000 (RO) 102E0000 (RO) 102F0000 (RO) 10300000 (RO) 10310000 (RO) 10320000 (RO) 10330000 (RO) 10340000 (RO) 10350000 (RO) 10360000 (RO) 10370000 (RO) 10380000 (RO) 10390000 (RO) 103A0000 (RO) 103B0000 (RO) 103C0000 (RO) 103D0000 (RO) 103E0000 (RO) 103F0000 (RO) Best Regards Morten

2 3

[U-Boot-Users] Porting U-Boot to an ARM920T-Based Board.
by Rodel Miguel 05 Oct '04

05 Oct '04

Hi, I would like to get some help to port u-boot on a new hardware (the hardware is still under heavy development). I have listed the following issues which I've encountered while reading the README and browsing the source tree. 1. My board has an ARM920T core. Instinctively, I would choose a "template" board support subdirectory that has the same core. If my platform is very different from the template, can I just choose the board that fits my needs (e.g. UART, FLASH, MEMORY MAP, etc.) and just re-configure the core? If this is possible, how do I do this? 2. My UART port is 16550 compliant. The ARM920T core (cpu/arm920T/) is using a serial.c that is compliant to S3C24XX. Can I just simply overwrite cpu/arm920t/serial.c with 16550 compliant serial.c? 3. Can somebody please tell me the files that are most-likely to change when porting u-boot to a new platform? Currently I am modifying the following: board/myboard /* copied from board smdk2410 */ - What should be placed here? Initialization routines? What is the "minimal" requirement for this subdirectory? Makefile - to make our board noticable to the main kernel tree include/configs/myboard.h 4. Are there other important files to modify in order to build the proper u-boot image? Please advise on the stated issues. Thank you very much. Regards, Rodel Miguel

2 1

[U-Boot-Users] fishing for ideas
by Benjamin Collar 05 Oct '04

05 Oct '04

Greetings folks Yesterday's problems have been overcome. Mostly I was just misunderstanding what was going on / what was supposed to be going on. Thanks for the clues overall. But there is a bit more to it. At the end of the day yesterday, I performed exactly the same 'loads' command, with exactly the same srec file, as I had done at the beginning of the day, and it worked. Talk about frustration! Today I was working on it and loaded a linux kernel image. When I 'loads' it, using the u-boot command line, into ram, the 'md' command at the loaded area shows 00010000: 27051956 d3232bea 415d1e66 0005ba2c '..V.#+.A].f..., 00010010: 7d8c5a14 3940ffff 914c0000 3bffffe0 }.Z.9@...L..;... 00010020: 4c696e75 782d322e 342e3138 00000000 Linux-2.4.18.... 00010030: 00000000 00000000 00000000 00000000 ................ while objdump shows 00000 27051956 d3232bea 415d1e66 0005ba2c '..V.#+.A].f..., 00010 00000000 00000000 82847f95 05070201 ................ 00020 4c696e75 782d322e 342e3138 00000000 Linux-2.4.18.... of course, you'll notice immediately that the 5th word is completely bogus, among others. I've spoken with the board developer (who also wrote a bootloader for the board) and showed him the sdram initialization function, and he said it was correct. However, I've got the behavior shown above. Is there another reason why this sort of corruption would happen? (btw, using 'cu' to download the image into RAM). Thanks for any tips Ben -- Benjamin Collar Siemens AG CT SE 2 Embedded Linux 089-636-53711

4 4

RE: [U-Boot-Users] How to compile U-boot using Metrowerks Code warrior on windows.
by VanBaren, Gerald (AGRE) 05 Oct '04

05 Oct '04

> -----Original Message----- > From: u-boot-users-admin(a)lists.sourceforge.net > [mailto:u-boot-users-admin@lists.sourceforge.net]On Behalf Of > Prathima_Kolar > Sent: Tuesday, October 05, 2004 2:15 AM > To: 'u-boot-users(a)lists.sourceforge.net' > Cc: Apoorv_Sangal; Nishant_Galange > Subject: [U-Boot-Users] How to compile U-boot using Metrowerks Code > warrior on windows. > > > Hi all, > > A little bird told me that the u-boot image created by Metrowerks > Codewarrior on windows is a lot smaller than the image > created by the gcc > tool chain. > > I need to verify the accuracy of that statement. So I > installed Codewarrior > on my (ugh) windows partition, but how do I tell Codewarrior > to compile my > u-boot source tree? The "Makefile Importer Wizard" gives a vague error > saying "no target found for Metrowerks EPPC" (or something > like that) when I > point it to the Makefile I got with u-boot. > > I'm completely new to Codewarrior, and reading the docs > didn't help at all. > Can somebody please help me out here? > > Waiting, > Prathima > > Ps. I'm using Codewarrior IDE ver. 5.5.1.1358 How much smaller did the little bird estimate? Unless you are at 101% of your available memory and have no more u-boot commands that you can disable, making u-boot smaller has no benefit. Jerry's Rule: Any memory that is not used by the program is wasted. This little bird says that disabling unnecessary commands is likely to save you more memory than changing compilers and it is much less painful. Building u-boot under Windows is swimming upstream through the rapids. Besides the obvious extra effort it takes, there are a lot of rocks in there. Building under Windows and simultaneously switching to an unfamiliar compiler is trying to swim/jump up a waterfall. I've seen salmon do it, but it is a huge effort and many of them never make it. Bottom line: Tell the little bird to verify the accuracy of his statement on his own (politely, of course, if he is your PHB). gvb ****************************************** The following messages are brought to you by the Lawyers' League of IdioSpeak: ****************************************** The information contained in, or attached to, this e-mail, may contain confidential information and is intended solely for the use of the individual or entity to whom they are addressed and may be subject to legal privilege. If you have received this e-mail in error you should notify the sender immediately by reply e-mail, delete the message from your system and notify your system manager. Please do not copy it for any purpose, or disclose its contents to any other person. The views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the company. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused, directly or indirectly, by any virus transmitted in this email. ******************************************

1 0

[U-Boot-Users] Resent: How to compile U-boot using Metrowerks Code warrior on wi ndows.
by Prathima_Kolar 05 Oct '04

05 Oct '04

Hi all, A little bird told me that the u-boot image created by Metrowerks Codewarrior on windows is a lot smaller than the image created by the gcc tool chain. I need to verify the accuracy of that statement. So I installed Codewarrior on my (ugh) windows partition, but how do I tell Codewarrior to compile my u-boot source tree? The "Makefile Importer Wizard" gives a vague error saying "no target found for Metrowerks EPPC" (or something like that) when I point it to the Makefile I got with u-boot. I'm completely new to Codewarrior, and reading the docs didn't help at all. Can somebody please help me out here? Waiting, Prathima Ps. I'm using Codewarrior IDE ver. 5.5.1.1358 ************************************************************************** This email (including any attachments) is intended for the sole use of the intended recipient/s and may contain material that is CONFIDENTIAL AND PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or distribution or forwarding of any or all of the contents in this message is STRICTLY PROHIBITED. If you are not the intended recipient, please contact the sender by email and delete all copies; your cooperation in this regard is appreciated. **************************************************************************

2 1

[U-Boot-Users] Resend:MPC8272 PCI bridge problem?
by Jack Liu 05 Oct '04

05 Oct '04

hi,all Sorry to resend this message here. But I really have a problem using MPC8272 PCI bridge. Currently I am debugging our own board with a MPC8272 and PCI IDE chip (VIA VT6410). However I can not visit the memory of PCI space. In u-boot, When I type "md F40001F0", there is always a program check. My configuration is as follows: * 0x00000000-0x07FFFFFF 128MB SDRAM * 0x80000000-0x9FFFFFFF 512MB outbound prefetchable PCI memory window * 0xA0000000-0xBFFFFFFF 512MB outbound non-prefetchable PCI memory window * 0xF0000000-0xF001FFFF 128KB MPC8272 internal memory * 0xF4000000-0xF7FFFFFF 64MB outbound PCI I/O window * 0xFE000000-0xFFFFFFFF 32MB flash /* PCIBR0 */ #define CFG_PCI_MSTR0_LOCAL 0x80000000 /* Local base */ #define CFG_PCIMSK0_MASK PCIMSK_1GB /* Size of window */ /* PCIBR1 */ #define CFG_PCI_MSTR1_LOCAL 0xF4000000 /* Local base */ #define CFG_PCIMSK1_MASK PCIMSK_64MB /* Size of window */ #define CFG_PCI_MSTR_IO_LOCAL 0xF4000000 /* Local base */ #define CFG_PCI_MSTR_IO_BUS 0xF4000000 /* PCI base */ #define CFG_CPU_PCI_IO_START PCI_MSTR_IO_LOCAL #define CFG_PCI_MSTR_IO_SIZE 0x04000000 /* 64MB */ #define CFG_POCMR2_MASK_ATTRIB (POCMR_MASK_64MB | POCMR_ENABLE | POCMR_PCI_IO) So, I am wondering why the configured PCI space can not be accessed since I have configured the outbound window and PCIBR? In MPC8241, I can access PCI space by "md FE0001F0". Any kind help will be greatly appreciated. Best regard Jack liu

2 1

[U-Boot-Users] How to compile U-boot using Metrowerks Code warrior on windows.
by Prathima_Kolar 05 Oct '04

05 Oct '04

Hi all, A little bird told me that the u-boot image created by Metrowerks Codewarrior on windows is a lot smaller than the image created by the gcc tool chain. I need to verify the accuracy of that statement. So I installed Codewarrior on my (ugh) windows partition, but how do I tell Codewarrior to compile my u-boot source tree? The "Makefile Importer Wizard" gives a vague error saying "no target found for Metrowerks EPPC" (or something like that) when I point it to the Makefile I got with u-boot. I'm completely new to Codewarrior, and reading the docs didn't help at all. Can somebody please help me out here? Waiting, Prathima Ps. I'm using Codewarrior IDE ver. 5.5.1.1358 ************************************************************************** This email (including any attachments) is intended for the sole use of the intended recipient/s and may contain material that is CONFIDENTIAL AND PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or distribution or forwarding of any or all of the contents in this message is STRICTLY PROHIBITED. If you are not the intended recipient, please contact the sender by email and delete all copies; your cooperation in this regard is appreciated. **************************************************************************

2 1

[U-Boot-Users] DB1000 Little-Endian U-Boot
by Charles Eidsness 04 Oct '04

04 Oct '04

Hi All, I would like to use u-boot on my DB1000 card (with an AMD Au1000 processor) in little endian mode. After a little bit of playing around I have gotten it to compile, load in to the parameter FLASH and run from the Yamon prompt, i.e. go bec00000. But, when I switch to boot completely from u-boot in the parameter flash (switch S8) the card just hangs. Does anyone have any ideas? Thanks, Charles

2 1

[U-Boot-Users] Getting Error Relocating the code
by raju rediff 04 Oct '04

04 Oct '04

Hi, We are porting u-boot on our card. We have take SBC board as reference and changed the code from that board's code. In the process, we got stuck-up with a problem of relocating the code. Please see the following dump. We are loading the code through emulator into the ram at address 0x00000000. ====================================================================== U-Boot 1.1.1 (Sep 22 2004 - 13:28:21) MPC8260 Reset Status: External Soft, External Hard MPC8260 Clock Configuration - Bus-to-Core Mult 4x, VCO Div 2, 60x Bus Freq 25-75 , Core Freq 100-300 - dfbrg 1, corecnf 0x1a, busdf 4, cpmdf 1, plldf 1, pllmf 4 - vco_out 330000000, scc_clk 82500000, brg_clk 20625000 - cpu_clk 264000000, cpm_clk 165000000, bus_clk 66000000 CPU: MPC8260 (HiP4 Rev 14, Mask B.1 4K25A) at 264 MHz Board: EST ALI8260 DRAM: Setup 60x SDRAM controller Setup Local SDRAM controller64 MB Bus Fault @ 0x00003388, fixup 0x00000000 Machine check in kernel mode. Caused by (from msr): regs 07fb5c58 Unknown values in msr NIP: 00003388 XER: 20000000 LR: 00004A20 REGS: 07fb5c58 TRAP: 0200 DAR: 46498442MSR: 00003000 EE: 0 PR: 0 FP: 1 ME: 1 IR/DR: 00 GPR00: 8408FFFC 07FB5D48 00000000 07FD6000 04000000 FC024000 00000020 03FD6000 GPR08: FFFFFFFC 07FB5D6C 07FD6000 07FB5DB4 00000020 00000000 03FFF000 03FD6000 GPR16: 00000000 00000000 00000000 00000000 0000A920 00000001 00001002 0000E87C GPR24: 00000000 00000000 00000001 07FB5D6C 07FD6000 F0003F80 03FFF0B4 07FB5D48 Call backtrace: machine check ======================================================================= The bus fault location @3388 corresponds to the function "relocate_code" from objdump. The header file of the card is attached to this mail. Please let us know if you can identify any problem with the header file. With Best Regards, Raju

2 1

[U-Boot-Users] cfi_flash.c
by Tolunay Orkun 04 Oct '04

04 Oct '04

We are using this driver with CSB272 and CSB472 (both PPC405 based boards). The driver works OK on CSB272 where flash is setup as 2 side-by- side chips each x16 and accessed via a 32 bit CS. However, on CSB472 we have some apparently minor issue somewhere. The flash is setup as 1 chip of x16 and accessed via a 16 bit chip select. The protect on/off, erase commands work well. cp command also work OK but after the flash write is completed it leaves the flash array in command mode instead of returning to read mode. The workaround for now is to reset the board after programming or issue a protect on/off command. The flash chip is an Intel 28F640 and I've sync to U-Boot CVS last monday. Has anyone seen this problem, made a patch? I've posted about this before a few months ago but there was more pressing issues to deal with. If someone has solved this problem and a patch is in pipeline, I would like to try it otherwise I need to get my hands dirty to find out why the array is left in command mode. Best regards, Tolunay

1 0

[U-Boot-Users] Usb support
by swamy 04 Oct '04

04 Oct '04

Hi, I am interested in knowing any development on bootloader (Uboot) to download kernel using usb port( PXA255) instead of serial or Ethernet? Thanks swamy

1 0

AW: [U-Boot-Users] problem with cfi_flash.c & AT91RM9200DK
by Martin Krause 04 Oct '04

04 Oct '04

Hi Morten, Morten wrotes on Montag, 4. Oktober 2004 12:40: > Hello ! > > I have exchanged the flash on my AT91RM9200DK with a > AT49BV320C cfi flash, > and done all needed mods to the config file, every thing > seems ok except > that it get the size of the flash > incorectly. > > It sayes that it is a 16x16 4m, 71 sector cfi complient > flash, when it > should be a 2097 x 16, 32m, 71 sector flash ? Why should it be 2097 x 16, 32m? The datasheet says the flash is organized 2M x 16. This means 2M (= 2^21 = 2.097.152) Addresses each 16 Bit (= word) wide. And this is a size of 4 MByte. > size_ratio 1 port 16 bits chip 16 bits ... > Bank # 1: CFI conformant FLASH (16 x 16) Size: 4 MB in 71 Sectors This means U-Boot has detected a flash that is connected to a 16 bit port (bus) and the flash chip itself has also a 16 bit wide interface. The dirver seems working correctly to me. Regards, Martin

1 0

RE: [U-Boot-Users] Relocate code
by Holger L. Bille 04 Oct '04

04 Oct '04

Hi Raju Sending HTML to this list is inconsiderate. Please don't! > <A target="_blank" HREF="http://clients.rediff.com/signature/track_sig.asp"><IMG SRC="http://ads.rediff.com/RealMedia/ads/adstream_nx.cgi/www.rediffmail.com/inbo…" BORDER=0 VSPACE=0 HSPACE=0></a> Sending tracking HTLM is downright rude! Don't do that! Not to this list - don't do it at all! Holger Bille -----Original Message----- From: u-boot-users-admin(a)lists.sourceforge.net on behalf of raju rediff Sent: Mon 2004-10-04 8:26 To: u-boot-users(a)lists.sourceforge.net Cc: Subject: [U-Boot-Users] Relocate code Hi, Can any of you tell what exactly "relocate_code" function does when a. u-boot code is fused into the prom b. u-boot code is loaded into RAM using emulator It will be grateful if you can tell taking sbc board as reference. With Best Regards, Raju

1 0

[U-Boot-Users] Relocate code
by raju rediff 04 Oct '04

04 Oct '04

Hi, Can any of you tell what exactly "relocate_code" function does when a. u-boot code is fused into the prom b. u-boot code is loaded into RAM using emulator It will be grateful if you can tell taking sbc board as reference. With Best Regards, Raju

1 0

[U-Boot-Users] pagetable / BDI2000 question
by Stuart Yoder 04 Oct '04

04 Oct '04

This is not specifically a u-boot question, but involves some things that knowledgeable u-boot person may have insight into. We are debugging a Linux kernel that has been booted via U-boot on our own custom PowerPC board-- 750GX processor. Early in the Linux kernel initialization our system bridge chip (Marvell 64360 / DiscoveryII) is remapped to a new virtual address (via the ioremap() kernel call). At that point the new virtual address returns bad data. Physical address is: 0xF1000000 Original virtual address: 0xF1000000 Remapped virtual address: 0xEF5F0000 After the remapping occurs the following is true: -programmatic/kernel access to virtual address 0xF1000000 returns good data -programmatic/kernel access to new virtual address 0xEF5F0000 returns bad data -access via the BDI2000 to address 0xF1000000 returns good data -access via the BDI2000 to address 0xEF5F0000 returns _good data_ THIS MAKES NO SENSE. The fact that the BDI2000 can read the data proves that the page table entry is good. Here is the key question: How is it possible that the same location in memory accessed via the BDI2000 and accessed programmatically return DIFFERENT values. This remapped location is not supposed to be cached since it is IO memory. We have the page table / mmu option turned on the BDI config. Also, the Linux kernel has the BDI2000 config option enabled. Stuart

2 1

[U-Boot-Users] [PATCH] Add support for OMAP242x/arm1136 and TI H4 omap242x reference board 2/2.
by Woodruff, Richard 01 Oct '04

01 Oct '04

Hello, This patch adds support for the TI OMAP2420 processor and its reference board the H4. It like other OMAP's it has multiple cores. The ARM core is an ARMv6-ARM1136JF-S. The patch is a bit big, but it mainly is new files, and a couple minor OMAP specific teaks to a few common files. The patch was done against the latest image out on ftp.denx.de (u-boot 1.1.2). I have been using a GCC-3.4.0 tool chain downloadable from Codesourcery to build this. GCC 3.4 is the first version of GCC which has ARMv6 support. Thus this tool chain is required for kernel builds as the v6 kernel makes use of v6 instructions. U-boot could be a bit more flexible, but all my testing so far has been with this version of GCC. The is currently split into two parts. Regards, Richard W.

1 0

[U-Boot-Users] [PATCH] Add support for OMAP242x/arm1136 and TI H4 omap242x reference board 1/2.
by Woodruff, Richard 01 Oct '04

01 Oct '04

Hello, This patch adds support for the TI OMAP2420 processor and its reference board the H4. It like other OMAP's it has multiple cores. The ARM core is an ARMv6-ARM1136JF-S. The patch is a bit big, but it mainly is new files, and a couple minor OMAP specific teaks to a few common files. The patch was done against the latest image out on ftp.denx.de (u-boot 1.1.2). I have been using a GCC-3.4.0 tool chain downloadable from Codesourcery to build this. GCC 3.4 is the first version of GCC which has ARMv6 support. Thus this tool chain is required for kernel builds as the v6 kernel makes use of v6 instructions. U-boot could be a bit more flexible, but all my testing so far has been with this version of GCC. The is currently split into two parts. Regards, Richard W.

1 0

[U-Boot-Users] [PATCH] - fixed missing System ACE CF device
by Sean Chang 01 Oct '04

01 Oct '04

Hi, If there are any problems please let me know and I'll be more than happy to fix it. This patch is applied against the u-boot 1.1.1 release. The CHANGELOG is below. Regards, Sean ======================================================================= CHANGELOG (ace_fat.patch): Patch by Sean Chang, 9 Aug 2004: Fixed missing System ACE CF device during get FAT partition info in fat_register_device function. =======================================================================

3 8

RE: [U-Boot-Users] fishing for ideas
by VanBaren, Gerald (AGRE) 01 Oct '04

01 Oct '04

> -----Original Message----- > From: u-boot-users-admin(a)lists.sourceforge.net > [mailto:u-boot-users-admin@lists.sourceforge.net]On Behalf Of Benjamin > Collar > Sent: Friday, October 01, 2004 12:04 PM > To: u-boot-users(a)lists.sourceforge.net > Subject: [U-Boot-Users] fishing for ideas > > > Greetings folks > > Yesterday's problems have been overcome. Mostly I was just > misunderstanding what was going on / what was supposed to be going on. > Thanks for the clues overall. > > But there is a bit more to it. At the end of the day yesterday, I > performed exactly the same 'loads' command, with exactly the > same srec > file, as I had done at the beginning of the day, and it worked. Talk > about frustration! > > Today I was working on it and loaded a linux kernel image. When I > 'loads' it, using the u-boot command line, into ram, the 'md' > command at > the loaded area shows > > 00010000: 27051956 d3232bea 415d1e66 0005ba2c '..V.#+.A].f..., > 00010010: 7d8c5a14 3940ffff 914c0000 3bffffe0 }.Z.9@...L..;... > 00010020: 4c696e75 782d322e 342e3138 00000000 Linux-2.4.18.... > 00010030: 00000000 00000000 00000000 00000000 ................ > > while objdump shows > > 00000 27051956 d3232bea 415d1e66 0005ba2c '..V.#+.A].f..., > 00010 00000000 00000000 82847f95 05070201 ................ > 00020 4c696e75 782d322e 342e3138 00000000 Linux-2.4.18.... > > of course, you'll notice immediately that the 5th word is completely > bogus, among others. > > I've spoken with the board developer (who also wrote a bootloader for > the board) and showed him the sdram initialization function, > and he said > it was correct. However, I've got the behavior shown above. Is there > another reason why this sort of corruption would happen? (btw, using > 'cu' to download the image into RAM). > > Thanks for any tips > Ben > > -- > Benjamin Collar > Siemens AG > CT SE 2 > Embedded Linux > 089-636-53711 Just because he said his bootloader works doesn't necessarily mean it really and truly works (I'm a skeptic: my first statement is invariably "show me"). Do you have caching enabled? Did he? Caching enables burst mode which is a well know cause of SDRAM corruption due to what appears to be and is claimed to be working initialization but actually is not correct. Can you create a situation where the same operation works on his bootloader but doesn't work on yours? Can you make his bootloader fail like yours when doing the same or similar operation (not necessarily downloading with cu)? Yours with no answers, just questions... gvb ****************************************** The following messages are brought to you by the Lawyers' League of IdioSpeak: ****************************************** The information contained in, or attached to, this e-mail, may contain confidential information and is intended solely for the use of the individual or entity to whom they are addressed and may be subject to legal privilege. If you have received this e-mail in error you should notify the sender immediately by reply e-mail, delete the message from your system and notify your system manager. Please do not copy it for any purpose, or disclose its contents to any other person. The views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the company. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused, directly or indirectly, by any virus transmitted in this email. ******************************************

1 0