May 2003 - U-Boot

[U-Boot-Users] loading linux in FADS860T board through u-boot-1.0.0
by RamanaYV 17 Mar '04

17 Mar '04

I was trying to load linux-2.4.4 in FADS860T board using u-boot-1.0.0. I have settted environment variables like ipaddr,serverip,ethaddr,bootargs bootfile and saved the environment. Then,i typed tftpboot to download image from server. Then,i typed bootm to start the booting process. System is stucked by showing "Uncompressing Kernel Image ... OK" sequence of these events r given below.can u please suggest, what i need to do to come out from this. Thank you. U-Boot 1.0.0 (Mar 17 2004 - 14:06:16) CPU: XPC86xxxZPnnD4 at 40 MHz: 4 kB I-Cache 4 kB D-Cache FEC present Board: FADS with db MPC821, MPC860 / MPC860SAR / MPC860T rev PILOT DRAM: (4 MB SDRAM) 4M 60ns DRAM: 8 MB FLASH: 2 MB In: serial Out: serial Err: serial Net: FEC ETHERNET =>printenv stdin=serial stdout=serial stderr=serial Environment size: 41/16380 bytes =>setenv ipaddr 192.168.1.115 =>setenv serverip 192.168.1.87 =>setenv ip 192.168.1.115 =>setenv ethaddr 00:30:bf:01:02:d0 =>setenv bootargs "root=/dev/nfs rw nfsroot=192.168.1.87:/opt/eldk/ppc8xx ip=192 .168.1.115:192.168.1.87:192.168.1.115:255.255.255.0:ppc::off" =>setenv bootfile "pImage_fads_fec" =>saveenv Saving Environment to Flash... Un-Protected 1 sectors Erasing Flash... . done Erased 1 sectors Writing to Flash... done Protected 1 sectors =>printenv stdin=serial stdout=serial stderr=serial ipaddr=192.168.1.115 serverip=192.168.1.87 ip=192.168.1.115 ethaddr=00:30:bf:01:02:d0 bootargs="root=/dev/nfs rw nfsroot=192.168.1.87:/opt/eldk/ppc8xx ip=192.168 1.11 5:192.168.1.87:192.168.1.115:255.255.255.0:ppc::off" bootfile="pImage_fads_fec" Environment size: 287/16380 bytes =>tftpboot TFTP from server 192.168.1.87; our IP address is 192.168.1.115 Filename 'pImage_fads_fec'. Load address: 0x100000 Loading: T invalid RARP header #####################################################TX timeout ############ ####################### done Bytes transferred = 448321 (6d741 hex) =>bootm ## Booting image at 00100000 . Image Name: Linux-2.4.4 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 448257 Bytes = 437.8 kB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Uncompressing Kernel Image ... OK

3 2

[U-Boot-Users] FADS860T board
by RamanaYV 17 Mar '04

17 Mar '04

I was trying to load linux-2.4.4 in FADS860T board using u-boot-1.0.0. i am getting the followin symptom, can anyone suggest to come out from this problem.. U-Boot 1.0.0 (Mar 17 2004 - 14:06:16) CPU: XPC86xxxZPnnD4 at 40 MHz: 4 kB I-Cache 4 kB D-Cache FEC present Board: FADS with db MPC821, MPC860 / MPC860SAR / MPC860T rev PILOT DRAM: (4 MB SDRAM) 4M 60ns DRAM: 8 MB FLASH: 2 MB In: serial Out: serial Err: serial Net: FEC ETHERNET =>printenv stdin=serial stdout=serial stderr=serial Environment size: 41/16380 bytes =>setenv ipaddr 192.168.1.115 =>setenv serverip 192.168.1.87 =>setenv ip 192.168.1.115 =>setenv ethaddr 00:30:bf:01:02:d0 =>setenv bootargs "root=/dev/nfs rw nfsroot=192.168.1.87:/opt/eldk/ppc8xx ip=192 .168.1.115:192.168.1.87:192.168.1.115:255.255.255.0:ppc::off" =>setenv bootfile "pImage_fads_fec" =>saveenv Saving Environment to Flash... Un-Protected 1 sectors Erasing Flash... . done Erased 1 sectors Writing to Flash... done Protected 1 sectors =>printenv stdin=serial stdout=serial stderr=serial ipaddr=192.168.1.115 serverip=192.168.1.87 ip=192.168.1.115 ethaddr=00:30:bf:01:02:d0 bootargs="root=/dev/nfs rw nfsroot=192.168.1.87:/opt/eldk/ppc8xx ip=192.168.1.11 5:192.168.1.87:192.168.1.115:255.255.255.0:ppc::off" bootfile="pImage_fads_fec" Environment size: 287/16380 bytes =>tftpboot TFTP from server 192.168.1.87; our IP address is 192.168.1.115 Filename 'pImage_fads_fec'. Load address: 0x100000 Loading: T invalid RARP header #####################################################TX timeout ############ ####################### done Bytes transferred = 448321 (6d741 hex) =>bootm ## Booting image at 00100000 ... Image Name: Linux-2.4.4 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 448257 Bytes = 437.8 kB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Uncompressing Kernel Image ... OK Thanks to all.

2 1

[U-Boot-Users] Linux kernel crash in the early_init function
by llandre 28 Aug '03

28 Aug '03

I have a problem with U-Boot on the 405EP eval. board. Everything works fine until the kernel takes control and the system hangs: ------------------------------------------------------------------------------------ U-Boot 0.2.0 (May 6 2003 - 12:04:15) CPU: IBM PowerPC 405EP Rev. A at 266.666 MHz (PLB=133, OPB=66, EBC=66 MHz) PCI async ext clock used (sync mode not supported), internal PCI arbd 16 kB I-Cache 16 kB D-Cache Board: ### No HW ID - assuming WALNUT405 I2C: ready DRAM: 128 MB Top of RAM usable for U-Boot at: 08000000 Reserving 192k for U-Boot at: 07fd0000 Reserving 132k for malloc() at: 07faf000 Reserving 112 Bytes for Board Info at: 07faef90 Reserving 44 Bytes for Global Data at: 07faef64 Stack Pointer at: 07faef48 New Stack Pointer is: 07faef48 Now running in RAM - U-Boot at: 07fd0000 FLASH: 512 kB [board.c, 767] Calling env_relocate ... env_relocate[203] offset = 0x8050000 env_relocate[221] malloced ENV at 07faf008 In: serial Out: serial Err: serial KGDB: kgdb ready ready U-Boot relocated to 07fd0000 [board.c, 913] Calling interrupt_init ... ### main_loop entered: bootdelay=3 ### main_loop: bootcmd="tftpboot 0x400000 vmlinux.PPCBoot" Hit any key to stop autoboot: 0 ENET Speed is 10 Mbps - HALF duplex connection TX_BUFF 0 @ 0x07fb0228 RX_BUFF 0 @ 0x07ff3fc0 RX_BUFF 1 @ 0x07ff45c0 RX_BUFF 2 @ 0x07ff4bc0 RX_BUFF 3 @ 0x07ff51c0 Install interrupt for vector 9 ==> 07fd49c0 Install interrupt for vector 10 ==> 07fd49c0 Install interrupt for vector 11 ==> 07fd49c0 Install interrupt for vector 12 ==> 07fd49c0 Install interrupt for vector 13 ==> 07fd49c0 Install interrupt for vector 14 ==> 07fd49c0 Install interrupt for vector 15 ==> 07fd49c0 ARP broadcast 1 Got good ARP - start TFTP TFTP from server 192.168.10.6; our IP address is 192.168.10.203 Filename 'vmlinux.PPCBoot'. Load address: 0x400000 Loading: ################################################################# ######################################### done Bytes transferred = 539758 (83c6e hex) Automatic boot of image at addr 0x00400000 ... ## Booting image at 00400000 ... Image Name: Linux-2.4.21-pre5 Created: 2003-05-06 11:42:31 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 539694 Bytes = 527 kB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Uncompressing Kernel Image ... OK ## Current stack ends at 0x07FAE5B8 => set upper limit to 0x00800000 ## cmdline at 0x007FFC00 ... 0x007FFC16 bd address = 0x07FAEF90 memstart = 0x00000000 memsize = 0x08000000 flashstart = 0xFFF80000 flashsize = 0x00080000 flashoffset = 0x00030000 sramstart = 0x00000000 sramsize = 0x00000000 bootflags = 0x6BBA3A55 procfreq = 266.666 MHz plb_busfreq = 133.333 MHz pci_busfreq = 33.333 MHz ethaddr = 00:50:C2:1E:AF:FE IP addr = 192.168.10.203 baudrate = 115200 bps No initrd ## Transferring control to Linux (at address 00000000) ... ------------------------------------------------------------------------------------ I found that the function memset_io, invoked by early_init, corrupts the memory region where the function identify_cpu is located. This is the disassembled produced by objdump: c0006774 <identify_cpu>: c0006774: 3d 03 c0 12 addis r8,r3,-16366 c0006778: 39 08 e1 40 addi r8,r8,-7872 c000677c: 7c ff 42 a6 mfpvr r7 c0006780: 80 a8 00 00 lwz r5,0(r8) c0006784: 7c a5 38 38 and r5,r5,r7 c0006788: 80 c8 00 04 lwz r6,4(r8) c000678c: 7c 06 28 40 cmplw r6,r5 c0006790: 41 82 00 0c beq- c000679c <identify_cpu+0x28> c0006794: 39 08 00 20 addi r8,r8,32 c0006798: 4b ff ff e8 b c0006780 <identify_cpu+0xc> c000679c: 3c c3 c0 14 addis r6,r3,-16364 c00067a0: 38 c6 f0 bc addi r6,r6,-3908 c00067a4: 54 84 10 3a rlwinm r4,r4,2,0,29 c00067a8: 7d 03 40 50 subf r8,r3,r8 c00067ac: 7d 04 31 2e stwx r8,r4,r6 c00067b0: 4e 80 00 20 blr This is what I see in memory before executing the memset_io: PPC405EP>go - TARGET: target has entered debug mode PPC405EP>md 0xc0006774 8 c0006774 : 0x3d03c012 1023655954 =... c0006778 : 0x3908e140 956883264 9..@ c000677c : 0x7cff42a6 2097103526 |.B. c0006780 : 0x80a80000 -2136473600 .... c0006784 : 0x7ca53838 2091202616 |.88 c0006788 : 0x80c80004 -2134376444 .... c000678c : 0x7c062840 2080778304 |.(@ c0006790 : 0x4182000c 1099038732 A... PPC405EP>go - TARGET: target has entered debug mode This is what I see in memory after executing the memset_io: PPC405EP>md 0xc0006774 8 c0006774 : 0xff03ffff - 16515073 .... c0006778 : 0xff08ffff - 16187393 .... c000677c : 0xff08ffff - 16187393 .... c0006780 : 0x80a80000 -2136473600 .... c0006784 : 0x7ca53838 2091202616 |.88 c0006788 : 0x80c80004 -2134376444 .... c000678c : 0x3c060840 1007028288 <..@ c0006790 : 0x7c062840 2080778304 |.(@ PPC405EP> Anybody have already seen something like that? Is it possible that this has to do with an erroneous cache initialization? Many thanks in advance. llandre

2 1

[U-Boot-Users] Patch for port I/O commands, 'in' and 'out'.
by Marc Singer 30 May '03

30 May '03

This patch provides port I/O commands for architectures that support them. AFAIK, the only current architecture using a separate IO space is IA32 (aka x86).

2 1

[U-Boot-Users] RE: Why S-Records?
by Wells, Charles 30 May '03

30 May '03

Rupesh, I always view the choice of S-records (or Intel hex or whatever) vs. binary records as being a matter of line bandwidth. The problem is, of course, that the ASCII hex characters take a bit more than twice as long to send. Note that even in the ancient minicomputer days (say 1969), the DEC paper tape loader was a binary loader. The problem here was that the terminal of choice was an ASR33 and loaded programs at 10 bytes per second. Even short programs took a very long time to load. A PDP11 might have 16k bytes of memory, so a 6k program was not unreasonable. This would take over 10 minutes to load. ASCII-based download formats became popular with the advent of microprocessors which originally had very limited memory but faster serial ports. The micro may have only 1k of program RAM and the serial port would run at 960 characters per second. So, the entire RAM could be loaded in just over 1 second. The problem was that the serial port used to download a program was also used as the console device and therefore had an ASCII terminal monitoring the line as well. If you sent binary over the line, it was echoed you would get unsightly garbage printed on the console. You also had to put up with the irritating noise of the bell. Worse yet, the binary characters would put VT100-style consoles into strange modes that you couldn't recover from. So, if you split one binary character into two ASCII hex characters, you never had to deal with a messy or noisy display. You could also just look at it and read it. Some of us got quiet good at this. Error detection and control is a totally different matter. If you're downloading a program, you always need to know that it got down there correctly, so you always need error detection (and possibly control). My preference is to add the extra error detection characters in the definition of the loader records, regardless of whether these loader records are ASCII or binary. This way you can move between physical transport methods (e.g., raw serial ports or TCP/IP/Ethernet) and simply not worry about whether the line discipline has error checking or not. With the speed of modern communications lines, the few percent of overhead for the checksums just doesn't matter. Just my $0.02. Regards, Charlie

1 0

[U-Boot-Users] u-boot & tftp problem
by Brian S. Park 30 May '03

30 May '03

Hi All, I'm using IBM walnut demo board (PPC 405GP) and u-boot 0.3.0 which I compiled using ELDK. From time to time, when I download new image using tftp protocol, I get the following error. Does any one here have seen this problem? I'd appreciate any help it tracking down the problem. Thak you. => tftpboo 100000 u-boot.bin ENET Speed is 100 Mbps - FULL duplex connection ARP broadcast 1 TFTP from server 192.168.1.78; our IP address is 192.168.1.146 Filename 'u-boot.bin'. Load address: 0x100000 Loading: ############################################## MAL error occured.... ISR = c0100010 UIC = = 2a0000 MAL_DEF = 2e0000 MAL_ERR= T T T MAL error occured.... ISR = c0100010 UIC = = 220000 MAL_DEF = 2e0000 MAL_ERR= T ERROR : Receive buffers are full! MAL error occured.... ISR = c0100010 UIC = = 220000 MAL_DEF = 2e0000 MAL_ERR= T T T =============================================================== Brian S. Park brian(a)corelis.com (562) 926-6727 x143 --------------------------------------------------------------- Everything we do helps our customers get to market FASTER with HIGHER quality and LOWER cost ===============================================================

1 0

[U-Boot-Users] Why S-Records?
by Rupesh S 30 May '03

30 May '03

Hi, Pardon me if this is out of scope in this groups.. The discussion is about usage of S-Record files for Downloads instead of Binary file. Generally S-Record Downloads are used when the medium of communication is Serial Port , which has no Error Checking mechanism inbuilt in hardware. Whereas when we consider the Network download throgh Ethernet, most bootloaders (u-boot as well) does a binary download. Is this because the Ethernet hardware has a Error Checking mechanism inbuilt ? If yes, even using a USB hardware for download also can use Binary instead of S-Records?? Please comment on my arguments? Rupesh

2 3

[U-Boot-Users] timers
by Gupta, Kshitij 30 May '03

30 May '03

hi, If you don't use the interrupts (i.e #undef CONFIG_USE_IRQ) and the timers which we have on board downcount timers which generate interrupts when they reach count of 0, then is it possible to maintain timers ?? If the interrupts are disabled then when the timer wraps around (auto reload) then there is no one to increment the wrap count, thus we loose the time. The only time I can see this working is when we are sure that we will get a get_timer() call every time before the timer wraps. I saw the code for smdk2410(Arm920t based) board and for this board the interrupts are disabled. If anyone can please guide me on this problem. regards -kshitij

1 0

[U-Boot-Users] [PATCH] net/rarp.c missing htons() calls
by Marc Singer 29 May '03

29 May '03

Rarp doesn't work on the little-endian IA32 without calling htons() when composing the RARP packet.

1 0

[U-Boot-Users] error when building sc520_cdp
by Frank 29 May '03

29 May '03

ld -Bstatic -T /home/fmcmurra/sis/u-boot/board/sc520_cdp/u-boot.lds -Ttext 0x387e0000 cpu/i386/start.o cpu/i386/start16.o cpu/i386/reset.o \ --start-group board/sc520_cdp/libsc520_cdp.a Hi, I am getting a linker error when I try to build the sc520_cdp board. I checked this out of cvs on 5/28. Has anyone successfully built this board and does anyone know how I can resolve this error. Thanks in advance... cpu/i386/libi386.a lib_i386/libi386.a fs/jffs2/libjffs2.a fs/fdos/libfdos.a net/libnet.a disk/libdisk.a rtc/librtc.a dtt/libdtt.a drivers/libdrivers.a post/libpost.a post/cpu/libcpu.a common/libcommon.a lib_generic/libgeneric.a --end-group \ -Map u-boot.map -o u-boot ld: section .data [387f5454 -> 387f660b] overlaps section .rodata.str1.1 [387f5454 -> 387f6c11] ld: section .realmode [387f660c -> 387f6771] overlaps section .rodata.str1.1 [387f5454 -> 387f6c11] ld: section .bios [387f6772 -> 387f6983] overlaps section .rodata.str1.1 [387f5454 -> 387f6c11] make: *** [u-boot] Error 1 __________________________________ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com

2 2