July 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] [PATCH] support for Intel IXP
by Kyle Harris 10 Oct '03

10 Oct '03

Wolfgang, Please find attached a patch for Intel CPU IXP425 and eval board IXDP425. This is applied against 0.4.0 (I tried several times to pull from CVS but failed, and finally gave up). Note: This patch does NOT include support for the PCI bridge :( Regards, Kyle.

3 8

[U-Boot-Users] (no subject)
by C Doyle 27 Sep '03

27 Sep '03

Hello all, Ive been trying to compile u-boot0.4 for the mpc8266ads board. I am using the hardhat ppc-cross compiler and am coming across problems with the compilation. First of all make fails at a bootp error which can be fixed by placing parenthesis around the #define. It next fails in the examples folder where I think it is trying the hello_world.bin & others and this can be fixed by doing a chmod on each of the examples it fails on. Just wondering if anyone is coming across the same problems and if any official fixes are available for this? After I change these the project compiles ok. Cheers _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus

2 1

[U-Boot-Users] u-boot on Memec P4/7-FG456 (w/ virtex II pro)?
by jds 12 Sep '03

12 Sep '03

hi, has anyone done any u-boot porting work for the Memec Virtex-II Pro P4/7-FG456 evaluation board? as you can see from the link below this is a development board which has the Virtex-II Pro (w/ single 405GP core) along with SDRAM, NV stroage via compact flash, and so forth. http://www.memec.com/cgi-bin/bvutf8/memec/scripts/local/manuDetailArticle.j… we are considering using this board as an R&D platfrom for an upcoming project. thanks! -- Perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away. - Antoine de Saint-Exupery

2 2

[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] DiscoveryII (Marvell MV64360) support?
by wombat＠ottawa.com 18 Aug '03

18 Aug '03

Hi folks, I was just curious what the status of (Marvell MV64360). I've looked around, and grabbed the latest 'u-boot' cvs snapshot and don't see any DISCOII support. I do see DISCOI (marvell 64260) support in include/galileo/*. Does anyone have plans to add that support to 'u-boot'? Doing some looking around, the only thing I could find was that Artesyn seems to have a cPCI PPC board with both DISCOII & 'ppcboot' (on their webpage, they probably haven't updated the webpage and they mean u-boot). http://www.artesyncp.com/products/Katana750i.html Any information would be greatly appreciated. thanks, Craig.

2 1

[U-Boot-Users] Function pointers after relocation
by Robin Gilks 03 Aug '03

03 Aug '03

Greetings When u-boot has relocated from Flash to RAM, it is correct that function pointers (eg. getenv()) still point to the Flash code rather than the RAM copy? Would this be corrected by changing the link address, in which case where do I find it (the link address that is) - in the .lds file? board = mpc866ads (fads alike) cpu = mpc866 (mpc860 alike) all changes based on ads860+fads merge!! -- Robin Gilks Senior Design Engineer Phone: (+64)(3) 357 1569 Tait Electronics Fax : (+64)(3) 359 4632 PO Box 1645 Christchurch Email : robin.gilks(a)tait.co.nz New Zealand

4 14

[U-Boot-Users] Compiling U-boot using ELDK on Mandrake9.1
by C Doyle 31 Jul '03

31 Jul '03

Hello, I am a student trying to get u-boot0.4.0 up and running on an MPC8266ADS board using ELDK as a cross compiler. I managed to get the ELDK installed what seems to be problem free. I am trying to cross compile u-boot0.4.0 for the MPC8266ADS development board. I have a Host PC running Mandrake 9.1 which I notice is about the only distribution that eldk has not been tested with. Has anyone managed to get u-boot0.4.0 compiled on Mandrake or can anyone tell me what the problem is in the astest.o symbol at the end of the Makefile output below? There seems to be some problem with the /opt/eldk/ppc_82xx/usr/lib/libbfd.so. Previously I have used a hardhat cross-compiler and noticed that it was using /libbfd.a as opposed to /libbfd.so. Do I need to export the symbols from libbfd.so? Any help would be greatly appreciated... Thanks, Ciaran Doyle I have made the following changes to the root dir Makefile: HOSTARCH := ppc ifndef CROSS_COMPILE ifeq ($(HOSTARCH),ppc) CROSS_COMPILE = /opt/eldk/usr/bin/ppc_82xx- else ifeq ($(ARCH),ppc) CROSS_COMPILE = ppc_8xx- endif And in the ./tools/gdb/Makefile I have updated the path as follows: astest: astest.o error.o $(CC) $(CFLAGS) $(HOST_LDFLAGS) -o $@ $^ -L$(BFD_ROOT_DIR)/lib -L /opt/eldk/ppc_82xx/usr/lib -lbfd -liberty I run the configuration script for u-boot0.4.0 [root@MPC8266 u-boot-0.4.0]# make MPC8266ADS_config rm -f include/config.h include/config.mk Configuring for MPC8266ADS board... -Followed by a make all (sorry for including all of the make output - just in case theres any clues in it): [root@MPC8266 u-boot-0.4.0]# make all make[1]: Entering directory `/u-boot-0.4.0/tools' ln -s ../common/environment.c environment.c ln -s ../lib_generic/crc32.c crc32.c gcc -M -Wall -pedantic -I../include -I.. -DTEXT_BASE=0xfe000000 -DUSE_HOSTCC environment.c img2srec.c mkimage.c crc32.c envcrc.c gen_eth_addr.c bmp_logo.c > .depend make[1]: Leaving directory `/u-boot-0.4.0/tools' make[1]: Entering directory `/u-boot-0.4.0/tools' make[1]: `.depend' is up to date. make[1]: Leaving directory `/u-boot-0.4.0/tools' make[1]: Entering directory `/u-boot-0.4.0/lib_generic' /opt/eldk/usr/bin/ppc_82xx-gcc -M -g -Os -mrelocatable -ffixed-r14 -meabi -D__KERNEL__ -DTEXT_BASE=0xfe000000 -I/u-boot-0.4.0/include -fno-builtin -nostdinc -isystem /opt/eldk/usr/lib/gcc-lib/ppc-linux/2.95.4/include -pipe -DCONFIG_PPC -D__powerpc__ -DCONFIG_8260 -ffixed-r2 -ffixed-r29 -mstring -mcpu=603e -mmultiple -DTEXT_BASE=0xfe000000 -I/u-boot-0.4.0/board -Wall -Wstrict-prototypes crc32.c ctype.c display_options.c ldiv.c string.c vsprintf.c zlib.c > .depend make[1]: Leaving directory `/u-boot-0.4.0/lib_generic' make[1]: Entering directory `/u-boot-0.4.0/lib_generic' make[1]: `.depend' is up to date. make[1]: Leaving directory `/u-boot-0.4.0/lib_generic' make[1]: Entering directory `/u-boot-0.4.0/lib_ppc' /opt/eldk/usr/bin/ppc_82xx-gcc -M -g -Os -mrelocatable -ffixed-r14 -meabi -D__KERNEL__ -DTEXT_BASE=0xfe000000 -I/u-boot-0.4.0/include -fno-builtin -nostdinc -isystem /opt/eldk/usr/lib/gcc-lib/ppc-linux/2.95.4/include -pipe -DCONFIG_PPC -D__powerpc__ -DCONFIG_8260 -ffixed-r2 -ffixed-r29 -mstring -mcpu=603e -mmultiple -DTEXT_BASE=0xfe000000 -I/u-boot-0.4.0/board -Wall -Wstrict-prototypes ppcstring.S ticks.S board.c bat_rw.c cache.c extable.c kgdb.c time.c > .depend make[1]: Leaving directory `/u-boot-0.4.0/lib_ppc' make[1]: Entering directory `/u-boot-0.4.0/lib_ppc' make[1]: `.depend' is up to date. make[1]: Leaving directory `/u-boot-0.4.0/lib_ppc' make[1]: Entering directory `/u-boot-0.4.0/cpu/mpc8260' /opt/eldk/usr/bin/ppc_82xx-gcc -M -g -Os -mrelocatable -ffixed-r14 -meabi -D__KERNEL__ -DTEXT_BASE=0xfe000000 -I/u-boot-0.4.0/include -fno-builtin -nostdinc -isystem /opt/eldk/usr/lib/gcc-lib/ppc-linux/2.95.4/include -pipe -DCONFIG_PPC -D__powerpc__ -DCONFIG_8260 -ffixed-r2 -ffixed-r29 -mstring -mcpu=603e -mmultiple -DTEXT_BASE=0xfe000000 -I/u-boot-0.4.0/board -Wall -Wstrict-prototypes start.S kgdb.S traps.c serial_smc.c serial_scc.c cpu.c cpu_init.c speed.c interrupts.c ether_scc.c ether_fcc.c i2c.c commproc.c bedbug_603e.c pci.c spi.c > .depend make[1]: Leaving directory `/u-boot-0.4.0/cpu/mpc8260' make[1]: Entering directory `/u-boot-0.4.0/cpu/mpc8260' make[1]: `.depend' is up to date. make[1]: Leaving directory `/u-boot-0.4.0/cpu/mpc8260' make[1]: Entering directory `/u-boot-0.4.0/board/mpc8266ads' /opt/eldk/usr/bin/ppc_82xx-gcc -M -g -Os -mrelocatable -ffixed-r14 -meabi -D__KERNEL__ -DTEXT_BASE=0xfe000000 -I/u-boot-0.4.0/include -fno-builtin -nostdinc -isystem /opt/eldk/usr/lib/gcc-lib/ppc-linux/2.95.4/include -pipe -DCONFIG_PPC -D__powerpc__ -DCONFIG_8260 -ffixed-r2 -ffixed-r29 -mstring -mcpu=603e -mmultiple -DTEXT_BASE=0xfe000000 -I/u-boot-0.4.0/board mpc8266ads.c flash.c > .depend make[1]: Leaving directory `/u-boot-0.4.0/board/mpc8266ads' make[1]: Entering directory `/u-boot-0.4.0/board/mpc8266ads' make[1]: `.depend' is up to date. make[1]: Leaving directory `/u-boot-0.4.0/board/mpc8266ads' make[1]: Entering directory `/u-boot-0.4.0/common' /opt/eldk/usr/bin/ppc_82xx-gcc -M -g -Os -mrelocatable -ffixed-r14 -meabi -D__KERNEL__ -DTEXT_BASE=0xfe000000 -I/u-boot-0.4.0/include -fno-builtin -nostdinc -isystem /opt/eldk/usr/lib/gcc-lib/ppc-linux/2.95.4/include -pipe -DCONFIG_PPC -D__powerpc__ -DCONFIG_8260 -ffixed-r2 -ffixed-r29 -mstring -mcpu=603e -mmultiple -DTEXT_BASE=0xfe000000 -I/u-boot-0.4.0/board -Wall -Wstrict-prototypes main.c altera.c bedbug.c cmd_autoscript.c cmd_bedbug.c cmd_bmp.c cmd_boot.c cmd_bootm.c cmd_cache.c cmd_console.c cmd_date.c cmd_dcr.c cmd_diag.c cmd_doc.c cmd_nand.c cmd_dtt.c cmd_eeprom.c cmd_elf.c cmd_fat.c cmd_fdc.c cmd_fdos.c cmd_flash.c cmd_fpga.c cmd_i2c.c cmd_ide.c cmd_immap.c cmd_jffs2.c cmd_log.c cmd_mem.c cmd_mii.c cmd_misc.c cmd_mmc.c cmd_net.c cmd_nvedit.c env_common.c env_flash.c env_eeprom.c env_nvram.c env_nowhere.c cmd_pci.c cmd_pcmcia.c cmd_portio.c cmd_reginfo.c cmd_scsi.c cmd_vfd.c cmd_usb.c command.c console.c devices.c dlmalloc.c docecc.c environment.c flash.c fpga.c hush.c kgdb.c lists.c miiphybb.c miiphyutil.c s_record.c soft_i2c.c soft_spi.c cmd_spi.c spartan2.c usb.c usb_kbd.c usb_storage.c virtex2.c xilinx.c > .depend make[1]: Leaving directory `/u-boot-0.4.0/common' make[1]: Entering directory `/u-boot-0.4.0/common' make[1]: `.depend' is up to date. make[1]: Leaving directory `/u-boot-0.4.0/common' make[1]: Entering directory `/u-boot-0.4.0/disk' /opt/eldk/usr/bin/ppc_82xx-gcc -M -g -Os -mrelocatable -ffixed-r14 -meabi -D__KERNEL__ -DTEXT_BASE=0xfe000000 -I/u-boot-0.4.0/include -fno-builtin -nostdinc -isystem /opt/eldk/usr/lib/gcc-lib/ppc-linux/2.95.4/include -pipe -DCONFIG_PPC -D__powerpc__ -DCONFIG_8260 -ffixed-r2 -ffixed-r29 -mstring -mcpu=603e -mmultiple -DTEXT_BASE=0xfe000000 -I/u-boot-0.4.0/board -Wall -Wstrict-prototypes part.c part_mac.c part_dos.c part_iso.c part_amiga.c > .depend make[1]: Leaving directory `/u-boot-0.4.0/disk' make[1]: Entering directory `/u-boot-0.4.0/disk' make[1]: `.depend' is up to date. make[1]: Leaving directory `/u-boot-0.4.0/disk' make[1]: Entering directory `/u-boot-0.4.0/fs' make[2]: Entering directory `/u-boot-0.4.0/fs/jffs2' /opt/eldk/usr/bin/ppc_82xx-gcc -M -g -Os -mrelocatable -ffixed-r14 -meabi -D__KERNEL__ -DTEXT_BASE=0xfe000000 -I/u-boot-0.4.0/include -fno-builtin -nostdinc -isystem /opt/eldk/usr/lib/gcc-lib/ppc-linux/2.95.4/include -pipe -DCONFIG_PPC -D__powerpc__ -DCONFIG_8260 -ffixed-r2 -ffixed-r29 -mstring -mcpu=603e -mmultiple -DTEXT_BASE=0xfe000000 -I/u-boot-0.4.0/board -Wall -Wstrict-prototypes jffs2_1pass.c compr_rtime.c compr_rubin.c compr_zlib.c mini_inflate.c > .depend make[2]: Leaving directory `/u-boot-0.4.0/fs/jffs2' make[2]: Entering directory `/u-boot-0.4.0/fs/jffs2' make[2]: `.depend' is up to date. make[2]: Leaving directory `/u-boot-0.4.0/fs/jffs2' make[2]: Entering directory `/u-boot-0.4.0/fs/fdos' /opt/eldk/usr/bin/ppc_82xx-gcc -M -g -Os -mrelocatable -ffixed-r14 -meabi -D__KERNEL__ -DTEXT_BASE=0xfe000000 -I/u-boot-0.4.0/include -fno-builtin -nostdinc -isystem /opt/eldk/usr/lib/gcc-lib/ppc-linux/2.95.4/include -pipe -DCONFIG_PPC -D__powerpc__ -DCONFIG_8260 -ffixed-r2 -ffixed-r29 -mstring -mcpu=603e -mmultiple -DTEXT_BASE=0xfe000000 -I/u-boot-0.4.0/board -Wall -Wstrict-prototypes fat.c vfat.c dev.c fdos.c fs.c subdir.c > .depend make[2]: Leaving directory `/u-boot-0.4.0/fs/fdos' make[2]: Entering directory `/u-boot-0.4.0/fs/fdos' make[2]: `.depend' is up to date. make[2]: Leaving directory `/u-boot-0.4.0/fs/fdos' make[2]: Entering directory `/u-boot-0.4.0/fs/fat' /opt/eldk/usr/bin/ppc_82xx-gcc -M -g -Os -mrelocatable -ffixed-r14 -meabi -D__KERNEL__ -DTEXT_BASE=0xfe000000 -I../..//include -fno-builtin -nostdinc -isystem /opt/eldk/usr/lib/gcc-lib/ppc-linux/2.95.4/include -pipe -DCONFIG_PPC -D__powerpc__ -DCONFIG_8260 -ffixed-r2 -ffixed-r29 -mstring -mcpu=603e -mmultiple -DTEXT_BASE=0xfe000000 -I../..//board -Wall -Wstrict-prototypes fat.c file.c > .depend make[2]: Leaving directory `/u-boot-0.4.0/fs/fat' make[2]: Entering directory `/u-boot-0.4.0/fs/fat' make[2]: `.depend' is up to date. make[2]: Leaving directory `/u-boot-0.4.0/fs/fat' make[1]: Leaving directory `/u-boot-0.4.0/fs' make[1]: Entering directory `/u-boot-0.4.0/net' /opt/eldk/usr/bin/ppc_82xx-gcc -M -g -Os -mrelocatable -ffixed-r14 -meabi -D__KERNEL__ -DTEXT_BASE=0xfe000000 -I/u-boot-0.4.0/include -fno-builtin -nostdinc -isystem /opt/eldk/usr/lib/gcc-lib/ppc-linux/2.95.4/include -pipe -DCONFIG_PPC -D__powerpc__ -DCONFIG_8260 -ffixed-r2 -ffixed-r29 -mstring -mcpu=603e -mmultiple -DTEXT_BASE=0xfe000000 -I/u-boot-0.4.0/board -Wall -Wstrict-prototypes net.c tftp.c bootp.c rarp.c eth.c > .depend make[1]: Leaving directory `/u-boot-0.4.0/net' make[1]: Entering directory `/u-boot-0.4.0/net' make[1]: `.depend' is up to date. make[1]: Leaving directory `/u-boot-0.4.0/net' make[1]: Entering directory `/u-boot-0.4.0/rtc' /opt/eldk/usr/bin/ppc_82xx-gcc -M -g -Os -mrelocatable -ffixed-r14 -meabi -D__KERNEL__ -DTEXT_BASE=0xfe000000 -I/u-boot-0.4.0/include -fno-builtin -nostdinc -isystem /opt/eldk/usr/lib/gcc-lib/ppc-linux/2.95.4/include -pipe -DCONFIG_PPC -D__powerpc__ -DCONFIG_8260 -ffixed-r2 -ffixed-r29 -mstring -mcpu=603e -mmultiple -DTEXT_BASE=0xfe000000 -I/u-boot-0.4.0/board -Wall -Wstrict-prototypes date.c ds12887.c ds1302.c ds1306.c ds1307.c ds1337.c ds1556.c ds164x.c ds174x.c m41t11.c m48t35ax.c mc146818.c mk48t59.c mpc8xx.c pcf8563.c s3c24x0_rtc.c > .depend make[1]: Leaving directory `/u-boot-0.4.0/rtc' make[1]: Entering directory `/u-boot-0.4.0/rtc' make[1]: `.depend' is up to date. make[1]: Leaving directory `/u-boot-0.4.0/rtc' make[1]: Entering directory `/u-boot-0.4.0/dtt' /opt/eldk/usr/bin/ppc_82xx-gcc -M -g -Os -mrelocatable -ffixed-r14 -meabi -D__KERNEL__ -DTEXT_BASE=0xfe000000 -I/u-boot-0.4.0/include -fno-builtin -nostdinc -isystem /opt/eldk/usr/lib/gcc-lib/ppc-linux/2.95.4/include -pipe -DCONFIG_PPC -D__powerpc__ -DCONFIG_8260 -ffixed-r2 -ffixed-r29 -mstring -mcpu=603e -mmultiple -DTEXT_BASE=0xfe000000 -I/u-boot-0.4.0/board -Wall -Wstrict-prototypes lm75.c ds1621.c adm1021.c > .depend make[1]: Leaving directory `/u-boot-0.4.0/dtt' make[1]: Entering directory `/u-boot-0.4.0/dtt' make[1]: `.depend' is up to date. make[1]: Leaving directory `/u-boot-0.4.0/dtt' make[1]: Entering directory `/u-boot-0.4.0/drivers' /opt/eldk/usr/bin/ppc_82xx-gcc -M -g -Os -mrelocatable -ffixed-r14 -meabi -D__KERNEL__ -DTEXT_BASE=0xfe000000 -I/u-boot-0.4.0/include -fno-builtin -nostdinc -isystem /opt/eldk/usr/lib/gcc-lib/ppc-linux/2.95.4/include -pipe -DCONFIG_PPC -D__powerpc__ -DCONFIG_8260 -ffixed-r2 -ffixed-r29 -mstring -mcpu=603e -mmultiple -DTEXT_BASE=0xfe000000 -I/u-boot-0.4.0/board -Wall -Wstrict-prototypes 3c589.c 5701rls.c ali512x.c bcm570x.c bcm570x_autoneg.c cfb_console.c cs8900.c ct69000.c dataflash.c dc2114x.c e1000.c eepro100.c i8042.c i82365.c inca-ip_sw.c lan91c96.c natsemi.c ns16550.c ns8382x.c ns87308.c pci.c pci_auto.c pci_indirect.c pcnet.c plb2800_eth.c s3c24x0_i2c.c sed13806.c serial.c serial_max3100.c smc91111.c smiLynxEM.c sym53c8xx.c ti_pci1410a.c tigon3.c w83c553f.c status_led.c > .depend make[1]: Leaving directory `/u-boot-0.4.0/drivers' make[1]: Entering directory `/u-boot-0.4.0/drivers' make[1]: `.depend' is up to date. make[1]: Leaving directory `/u-boot-0.4.0/drivers' make[1]: Entering directory `/u-boot-0.4.0/post' /opt/eldk/usr/bin/ppc_82xx-gcc -M -g -Os -mrelocatable -ffixed-r14 -meabi -D__KERNEL__ -DTEXT_BASE=0xfe000000 -I/u-boot-0.4.0/include -fno-builtin -nostdinc -isystem /opt/eldk/usr/lib/gcc-lib/ppc-linux/2.95.4/include -pipe -DCONFIG_PPC -D__powerpc__ -DCONFIG_8260 -ffixed-r2 -ffixed-r29 -mstring -mcpu=603e -mmultiple -DTEXT_BASE=0xfe000000 -I/u-boot-0.4.0/board -Wall -Wstrict-prototypes cache_8xx.S post.c tests.c cpu.c rtc.c watchdog.c memory.c i2c.c cache.c sysmon.c uart.c ether.c usb.c spr.c > .depend make[1]: Leaving directory `/u-boot-0.4.0/post' make[1]: Entering directory `/u-boot-0.4.0/post' make[1]: `.depend' is up to date. make[1]: Leaving directory `/u-boot-0.4.0/post' make[1]: Entering directory `/u-boot-0.4.0/post/cpu' /opt/eldk/usr/bin/ppc_82xx-gcc -M -g -Os -mrelocatable -ffixed-r14 -meabi -D__KERNEL__ -DTEXT_BASE=0xfe000000 -I/u-boot-0.4.0/include -fno-builtin -nostdinc -isystem /opt/eldk/usr/lib/gcc-lib/ppc-linux/2.95.4/include -pipe -DCONFIG_PPC -D__powerpc__ -DCONFIG_8260 -ffixed-r2 -ffixed-r29 -mstring -mcpu=603e -mmultiple -DTEXT_BASE=0xfe000000 -I/u-boot-0.4.0/board -Wall -Wstrict-prototypes asm.S cmp.c cmpi.c two.c twox.c three.c threex.c threei.c andi.c srawi.c rlwnm.c rlwinm.c rlwimi.c store.c load.c cr.c b.c multi.c string.c complex.c > .depend make[1]: Leaving directory `/u-boot-0.4.0/post/cpu' make[1]: Entering directory `/u-boot-0.4.0/post/cpu' make[1]: `.depend' is up to date. make[1]: Leaving directory `/u-boot-0.4.0/post/cpu' make[1]: Entering directory `/u-boot-0.4.0/examples' /opt/eldk/usr/bin/ppc_82xx-gcc -M -g -Os -mrelocatable -ffixed-r14 -meabi -D__KERNEL__ -DTEXT_BASE=0xfe000000 -I/u-boot-0.4.0/include -fno-builtin -nostdinc -isystem /opt/eldk/usr/lib/gcc-lib/ppc-linux/2.95.4/include -pipe -DCONFIG_PPC -D__powerpc__ -DCONFIG_8260 -ffixed-r2 -ffixed-r29 -mstring -mcpu=603e -mmultiple -DTEXT_BASE=0xfe000000 -I/u-boot-0.4.0/board -Wall -Wstrict-prototypes hello_world.c sched.c mem_to_mem_idma2intr.c syscall.S ppc_longjmp.S ppc_setjmp.S > .depend make[1]: Leaving directory `/u-boot-0.4.0/examples' make[1]: Entering directory `/u-boot-0.4.0/examples' make[1]: `.depend' is up to date. make[1]: Leaving directory `/u-boot-0.4.0/examples' make[1]: Entering directory `/u-boot-0.4.0/tools' gcc -Wall -pedantic -I../include -I.. -DTEXT_BASE=0xfe000000 -DUSE_HOSTCC -O -c -o img2srec.o img2srec.c gcc -Wall -pedantic -I../include -I.. -DTEXT_BASE=0xfe000000 -DUSE_HOSTCC -O -o img2srec img2srec.o strip img2srec gcc -g -Wall -pedantic -I../include -I.. -DTEXT_BASE=0xfe000000 -DUSE_HOSTCC -O -c mkimage.c gcc -g -Wall -pedantic -I../include -I.. -DTEXT_BASE=0xfe000000 -DUSE_HOSTCC -O -c crc32.c gcc -Wall -pedantic -I../include -I.. -DTEXT_BASE=0xfe000000 -DUSE_HOSTCC -O -o mkimage mkimage.o crc32.o strip mkimage gcc -g -Wall -pedantic -I../include -I.. -DTEXT_BASE=0xfe000000 -DUSE_HOSTCC -O -c envcrc.c gcc -g -I../include -I.. -DTEXT_BASE=0xfe000000 -DUSE_HOSTCC -c environment.c gcc -Wall -pedantic -I../include -I.. -DTEXT_BASE=0xfe000000 -DUSE_HOSTCC -O -o envcrc envcrc.o crc32.o environment.o gcc -g -Wall -pedantic -I../include -I.. -DTEXT_BASE=0xfe000000 -DUSE_HOSTCC -O -c gen_eth_addr.c gcc -Wall -pedantic -I../include -I.. -DTEXT_BASE=0xfe000000 -DUSE_HOSTCC -O -o gen_eth_addr gen_eth_addr.o strip gen_eth_addr gcc -Wall -pedantic -I../include -I.. -DTEXT_BASE=0xfe000000 -DUSE_HOSTCC -O -c -o bmp_logo.o bmp_logo.c gcc -Wall -pedantic -I../include -I.. -DTEXT_BASE=0xfe000000 -DUSE_HOSTCC -O -o bmp_logo bmp_logo.o strip bmp_logo ./bmp_logo logos/denx.bmp >/u-boot-0.4.0/include/bmp_logo.h make[2]: Entering directory `/u-boot-0.4.0/tools/gdb' gcc -M -I/opt/eldk/ppc_82xx/include -I../include gdbsend.c gdbcont.c astest.c error.c remote.c serial.c > .depend make[2]: Leaving directory `/u-boot-0.4.0/tools/gdb' make[2]: Entering directory `/u-boot-0.4.0/tools/gdb' gcc -Wall -pedantic -O -I/opt/eldk/ppc_82xx/include -I /opt/eldk/ppc_82xx/lib -c -o gdbsend.o gdbsend.c gcc -Wall -pedantic -O -I/opt/eldk/ppc_82xx/include -I /opt/eldk/ppc_82xx/lib -c -o error.o error.c gcc -Wall -pedantic -O -I/opt/eldk/ppc_82xx/include -I /opt/eldk/ppc_82xx/lib -c -o remote.o remote.c gcc -Wall -pedantic -O -I/opt/eldk/ppc_82xx/include -I /opt/eldk/ppc_82xx/lib -c -o serial.o serial.c gcc -Wall -pedantic -O -I/opt/eldk/ppc_82xx/include -I /opt/eldk/ppc_82xx/lib -o gdbsend gdbsend.o error.o remote.o serial.o gcc -Wall -pedantic -O -I/opt/eldk/ppc_82xx/include -I /opt/eldk/ppc_82xx/lib -c -o gdbcont.o gdbcont.c gcc -Wall -pedantic -O -I/opt/eldk/ppc_82xx/include -I /opt/eldk/ppc_82xx/lib -o gdbcont gdbcont.o error.o remote.o serial.o gcc -Wall -pedantic -O -I/opt/eldk/ppc_82xx/include -I /opt/eldk/ppc_82xx/lib -c -o astest.o astest.c gcc -Wall -pedantic -O -I/opt/eldk/ppc_82xx/include -I /opt/eldk/ppc_82xx/lib -o astest astest.o error.o -L/opt/eldk/ppc_82xx/lib -L /opt/eldk/ppc_82xx/usr/lib -lbfd -liberty /opt/eldk/ppc_82xx/usr/lib/libbfd.so: could not read symbols: Invalid operation collect2: ld returned 1 exit status make[2]: *** [astest] Error 1 make[2]: Leaving directory `/u-boot-0.4.0/tools/gdb' make[1]: *** [subdirs] Error 1 make[1]: Leaving directory `/u-boot-0.4.0/tools' make: *** [subdirs] Error 1 [root@MPC8266 u-boot-0.4.0]# _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail

2 1

[U-Boot-Users] Using MPC8xx SCC?
by Steven Scholz 31 Jul '03

31 Jul '03

Hi there, I have a display connected to SCC1 and want to display some boot message while the real console for U-Boot and Linux should be SMC1? What would be the best way to do so? Thanks a million, Steven

1 0

[U-Boot-Users] help in customizing uboot for inhouse board
by nikhil bhargav 31 Jul '03

31 Jul '03

hello friends, I am currently working on customization of uboot for inhouse mpc 860 based board. I have studied my board parameters and mpc 860 manuals and currently studying the source code of uboot. I am closely following the queries n solutions in this group. My problem is how to get started in modifying the code as per my board. Any pointers regarding this will help me to get the process kicked. bye, nikhil Nikhil Bhargav, Research Engineer, IMT - 2000 CDOT, Delhi India ___________________________________________________ Download the hottest & happening ringtones here! OR SMS: Top tone to 7333 Click here now: http://sms.rediff.com/cgi-bin/ringtone/ringhome.pl

2 1

[U-Boot-Users] [Q] mpc8245 PortX
by 배장식 31 Jul '03

31 Jul '03

i want to access extended rom area (0x70000000) in mpc8245 sandpoint board (ARTis Microsystems A-3000) i tried to reallocate BAT1(initial stack area ) 0x40000000 to 0x70000000 but board was hang... i wrote BAT1 reallocation function and call BAT1 reallocation function in board.c ( board_init_r () ) void move_bat1 (void) { mtspr (IBAT1L, (0x70000000 | BATL_PP_10 | BATL_CACHEINHIBIT)); mtspr (IBAT1U, (0x70000000 | BATU_BL_256M | BATU_VS | BATU_VP)); mtspr (DBAT1L, (0x70000000 | BATL_PP_10 | BATL_CACHEINHIBIT)); mtspr (DBAT1U, (0x70000000 | BATU_BL_256M | BATU_VS | BATU_VP)); __asm__ __volatile__("eieio"); __asm__ __volatile__("isync"); __asm__ __volatile__("sync"); } i think ram use stack at this function so 0x40000000 nerver accessed what's wrong... :-(( ^^ best regard~~

1 0

[U-Boot-Users] ep7312 address problem
by pure lau 31 Jul '03

31 Jul '03

Hi all: Now I am working on a EP7312 board with uboot and I have been blocked by a unknown problem for several week.Before descride the problem,let me intrduce my working flow. I compile u-boot under rh linux 7.3 with cross-compile tools download from arm.linux.org.uk. At the time I get u-boot.bin via cross-compile, I generate u-boot.asm by "arm-linux-objdump -d u-boot > u-boot.asm" Then program the u-boot.bin to flash(sst29vf040) with programmer. Switch the ep7312 board to external boot mode ,and begin boot. I use ICE and ADS 1.2 to trace how the board works.And I can trace that u-boot has init the ep7312 board and has relocated it self form flash(0x0) to sdram (0xc0f00000). The following is a piece of code in the sdram: (near the start of <start_armboot>) ------------------------------------------------ c0f00a50: [0xe92d40f0] stmfd r13!,{r4-r7,r14} c0f00a54: [0xe24dd088] sub r13,r13,#0x88 c0f00a58: [0xe28d8068] add r8,r13,#0x68 c0f00a5c: [0xe1a00008] mov r0,r8 c0f00a60: [0xe3a01000] mov r1,#0 c0f00a64: [0xe3a02020] mov r2,#0x20 c0f00a68: [0xeb002826] bl 0xc0f0ab08 ------------------------------------------------- please note the last line :(wrong,u-boot crashes here) ------------------------------------------------- c0f00a68: [0xeb002826] bl 0xc0f0ab08 ------------------------------------------------- In u-boot.asm and in flash ,this piece of code was: ------------------------------------------------- c0f00a50 <start_armboot>: c0f00a50: e92d40f0 stmdb sp!, {r4, r5, r6, r7, lr} c0f00a54: e24dd088 sub sp, sp, #136 ; 0x88 c0f00a58: e28d8068 add r8, sp, #104 ; 0x68 c0f00a5c: e1a00008 mov r0, r8 c0f00a60: e3a01000 mov r1, #0 ; 0x0 c0f00a64: e3a02020 mov r2, #32 ; 0x20 c0f00a68: eb002926 bl c0f0af08 <memset> ------------------------------------------------- where the last line was :(right,u-boot jump to <memset>) ------------------------------------------------- c0f00a68: eb002926 bl c0f0af08 <memset> ------------------------------------------------- we can compare the wrong and right line and find that the two BL address have a discrepancy of 0x400. (c0f0ab08 and c0f0af08).This makes u-boot to crash. I have been blocked here for several weeks.The content of u-boot.asm seems all right and in flash it does.But why after relocating to sdram the BL operating number subtracts 0x400? ------------------------------------------------------ the detailed info of my ep7312 board is as follows: cpu : EP7312 sdram: (4 bank * 1M * 16 bit) * 2 flash: 512k * 8 bit cs0 has been set to 8bit,slowest. ep7312.h and memsetup.S also attached. ------------------------------------------------------- Any one can help? Thanks in advance! Pure _________________________________________________________________ 与联机的朋友进行交流，请使用 MSN Messenger: http://messenger.msn.com/cn

1 0

[U-Boot-Users] ep7312 address problem
by pure lau 31 Jul '03

31 Jul '03

Hi all: Now I am working on a EP7312 board with uboot and I have been blocked by a unknown problem for several week.Before descride the problem,let me intrduce my working flow. I compile u-boot under rh linux 7.3 with cross-compile tools download from arm.linux.org.uk. At the time I get u-boot.bin via cross-compile, I generate u-boot.asm by "arm-linux-objdump -d u-boot > u-boot.asm" Then program the u-boot.bin to flash(sst29vf040) with programmer. Switch the ep7312 board to external boot mode ,and begin boot. I use ICE and ADS 1.2 to trace how the board works.And I can trace that u-boot has init the ep7312 board and has relocated it self form flash(0x0) to sdram (0xc0f00000). The following is a piece of code in the sdram: (near the start of <start_armboot>) ------------------------------------------------ c0f00a50: [0xe92d40f0] stmfd r13!,{r4-r7,r14} c0f00a54: [0xe24dd088] sub r13,r13,#0x88 c0f00a58: [0xe28d8068] add r8,r13,#0x68 c0f00a5c: [0xe1a00008] mov r0,r8 c0f00a60: [0xe3a01000] mov r1,#0 c0f00a64: [0xe3a02020] mov r2,#0x20 c0f00a68: [0xeb002826] bl 0xc0f0ab08 ------------------------------------------------- please note the last line :(wrong,u-boot crashes here) ------------------------------------------------- c0f00a68: [0xeb002826] bl 0xc0f0ab08 ------------------------------------------------- In u-boot.asm and in flash ,this piece of code was: ------------------------------------------------- c0f00a50 <start_armboot>: c0f00a50: e92d40f0 stmdb sp!, {r4, r5, r6, r7, lr} c0f00a54: e24dd088 sub sp, sp, #136 ; 0x88 c0f00a58: e28d8068 add r8, sp, #104 ; 0x68 c0f00a5c: e1a00008 mov r0, r8 c0f00a60: e3a01000 mov r1, #0 ; 0x0 c0f00a64: e3a02020 mov r2, #32 ; 0x20 c0f00a68: eb002926 bl c0f0af08 <memset> ------------------------------------------------- where the last line was :(right,u-boot jump to <memset>) ------------------------------------------------- c0f00a68: eb002926 bl c0f0af08 <memset> ------------------------------------------------- we can compare the wrong and right line and find that the two BL address have a discrepancy of 0x400. (c0f0ab08 and c0f0af08).This makes u-boot to crash. I have been blocked here for several weeks.The content of u-boot.asm seems all right and in flash it does.But why after relocating to sdram the BL operating number subtracts 0x400? ------------------------------------------------------ the detailed info of my ep7312 board is as follows: cpu : EP7312 sdram: (4 bank * 1M * 16 bit) * 2 flash: 512k * 8 bit cs0 has been set to 8bit,slowest. ep7312.h and memsetup.S also attached. ------------------------------------------------------- Any one can help? Thanks in advance! Pure _________________________________________________________________ 与联机的朋友进行交流，请使用 MSN Messenger: http://messenger.msn.com/cn

1 0

[U-Boot-Users] mpc8245 Portx BAT setting...
by 배장식 31 Jul '03

31 Jul '03

I have tried to configure PortX for use of memory space 0x7000_0000. I have modified MCCR4[EXTROM] to enable entened ROM. but i can't accessed address 0x70000000 ... i find something worng in include/config_Sandpint8245.h according to define BATs in config_Sandpint8245.h not allocate BATs for address 0x7000000 , so i try change BAT1 for extended rom i modify ppcboot code to blow list 1. 0x40000000 used by initial stack , until sdram init....(BAT1 allocation) 2. command/board.c : board_init_r () this function use stack...in ram so no more need 0x40000000 3. my added code to BAT1 realloction for 0x70000000.. void move_bat1 (void) { mtspr (IBAT1L, (0x70000000 | BATL_PP_10 | BATL_CACHEINHIBIT)); mtspr (IBAT1U, (0x70000000 | BATU_BL_256M | BATU_VS | BATU_VP)); mtspr (DBAT1L, (0x70000000 | BATL_PP_10 | BATL_CACHEINHIBIT)); mtspr (DBAT1U, (0x70000000 | BATU_BL_256M | BATU_VS | BATU_VP)); __asm__ __volatile__("eieio"); __asm__ __volatile__("isync"); __asm__ __volatile__("sync"); } 4. call move_bat1 at board_init_r ...... but...board not working.....

3 2

[U-Boot-Users] [Q]MPC8245 Extended Rom Setting
by 배장식 31 Jul '03

31 Jul '03

i want to access extended rom area (0x70000000) in mpc8245 sandpoint board (ARTis Microsystems A-3000) i tried to reallocate BAT1(initial stack area ) 0x40000000 to 0x70000000 but board was hang... i wrote BAT1 reallocation function and call BAT1 reallocation function in board.c ( board_init_r () ) void move_bat1 (void) { mtspr (IBAT1L, (0x70000000 | BATL_PP_10 | BATL_CACHEINHIBIT)); mtspr (IBAT1U, (0x70000000 | BATU_BL_256M | BATU_VS | BATU_VP)); mtspr (DBAT1L, (0x70000000 | BATL_PP_10 | BATL_CACHEINHIBIT)); mtspr (DBAT1U, (0x70000000 | BATU_BL_256M | BATU_VS | BATU_VP)); __asm__ __volatile__("eieio"); __asm__ __volatile__("isync"); __asm__ __volatile__("sync"); } i think ram use stack at this function so 0x40000000 nerver accessed what's wrong... :-(( ^^ best regard~~

1 0

RE: [U-Boot-Users] PATCH : Allow dhcp to get IP address from and keep other env data .
by Woodruff, Richard 30 Jul '03

30 Jul '03

Yes that's ok. I think most of those fields in dhcp are optional, as a client I think you can even send requests with them included as suggestions to the server. A while ago I had some similar issues with the kernel's built in dhcp code and had read though the RFC back then, but its been a while (my problem then was ATAGS were not being set properly thus overrides were not being processed correctly). The kernel does allow you to dhcp for an address and allows overrides with what ever the dhcp server sends back via boot/init parameters. I would think u-boot should do the same. The issue with u-boot would seem to be which and "when" environment variable parameters should override dhcp server reply information. I was taking the stance that if you have sent them in env then the code should use them even if they are NOT reasonable. Effort could be made to check and see if variables from the environment and reply are reasonable before setting them, but that seems like to much work at this level....and the desired functionality can be obtained and now has been sort of documented in discussion. Regards, Richard W. > -----Original Message----- > From: Wolfgang Denk [mailto:wd@denx.de] > Sent: Wednesday, July 30, 2003 10:35 AM > To: Woodruff, Richard > Cc: u-boot-users(a)lists.sourceforge.net > Subject: Re: [U-Boot-Users] PATCH : Allow dhcp to get IP > address from and keep other env data . > > > In message > <FD2AC9A020DDD51194710008C7089B200BEE2232(a)dlee17.itg.ti.com> > you wrote: > > > > Yes, this does work. I hadn't considered this sequence. In > some sense > > it's as much a workaround as a valid solution. The flexibility of > > having a shell like interpreter goes a long way. I will > likely stick > > with my code to keeps the steps down. > > I'm not sure what standard behaviour for DHCP requires - for > now, I think I will not change the code. Is this OK with you? > > > Best regards, > > Wolfgang Denk > > -- > Software Engineering: Embedded and Realtime Systems, Embedded Linux > Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: > wd(a)denx.de One of the advantages of being a captain is being > able to ask for ad- vice without necessarily having to take it. > -- Kirk, "Dagger of the Mind", stardate 2715.2 >

1 0

RE: [U-Boot-Users] PATCH : Allow dhcp to get IP address from and keep other env data .
by Woodruff, Richard 30 Jul '03

30 Jul '03

Hi Wolfgang, Yes, this does work. I hadn't considered this sequence. In some sense it's as much a workaround as a valid solution. The flexibility of having a shell like interpreter goes a long way. I will likely stick with my code to keeps the steps down. Best Regards, Richard W. > -----Original Message----- > From: Wolfgang Denk [mailto:wd@denx.de] > > > > => setenv my_bootfile "/tftpboot/foo" > > => setenv my_tftpserver XXX.XXX.XXX.XXX > > => saveenv > > > > => setenv autoload no > > => dhcp > > => setenv serverip $(my_tftpserver) > > => tftp 200000 $(my_bootfile) > > Doesn't this work for you?

2 1

RE: [U-Boot-Users] PATCH : Allow dhcp to get IP address from and keep other env data .
by Woodruff, Richard 30 Jul '03

30 Jul '03

Wolfgang, Seems to be some misunderstanding here. For the site I'm working at the global network is administrated by people in another location, and for some things in another city. All my "work" computers get their IP address via dhcp. If for convience sake I want to use my embedded target on the main network (its common for me to just NFS mount my development system for a built in root, or shared file system), all I can do easily is to use a static IP address which I either assign in a semi-unsafe way, or request one and wait. This works fine for just one person in small scale but when any number of people want to develop in a similar way things start to get messy. A dhcp server on my own machine with a lot of careful settings could be set up on my work station, however the networking administrators are very paranoid about running dhcp servers on the live network....and with some reason....hundreds of machines have been brought down in the past by people trying and mis-configuring. A second and more correct alternative, is to set up private networks off of workstations, unfortunately not all workstations are created equal in the number of interfaces they are shipped with, and even if they were its more effort to set up routing and the like to get it working properly. So, the shorter term and easier approach is to run a tftpserver on a workstation on the main network to deliver files, AND just use the main networks dhcp server for a valid IP address & netmask & gateway information. Now here is where u-boot comes in ... If I issue the dhcp command, the global dhcp server will NOT fill in bootfile name and the server name fields in optional fields. HOWEVER, the u-boot code _DOES_ write the NULLs back to the defaults (beneath the env names) making them unusable. ... the variable BootFile in memory always gets the first path argument stomped, and the server is zero'ed and not set. So, the patch I applied allows me to use the global dhcp server which I can ONLY ask address of, to give a valid address, and my environment variables allow resolution of my tftpserver and bootfile name. and all in one command. Hopefully this is clear, Regards, Richard W. -----Original Message----- From: Wolfgang Denk [mailto:wd@denx.de] Sent: Wednesday, July 30, 2003 2:13 AM To: Woodruff, Richard Cc: u-boot-users(a)lists.sourceforge.net Subject: Re: [U-Boot-Users] PATCH : Allow dhcp to get IP address from and keep other env data . Dear Richard, in message <FD2AC9A020DDD51194710008C7089B200BEE2230(a)dlee17.itg.ti.com> you wrote: > > This small patch adds the conditional DHCP_IP_ADDR_ONLY . This allows > someone to use the dhcp command to load a file on a network where you DON'T > have access to the dhcp server, but would like to use it to have fast > downloads of development kernels or other files. I have to admit that I don't understand this sentence. How can you use "it" (the dhcp server?), when you don't have access to it? > Prior to this patch the the reply packet would trash your environment > settings for bootfile and serverip will not be used when issuing the dhcp Sorry, but I disagree. Those variables will be _set_, not trashed. And only if your DHCP server transmits this sort of ionformation. If you don't want it, don't send it, i. e. configure your DHCP server not to send it. > command. By adding the CFG_DHCP_CMD, along with DHCP_IP_ADDR_ONLY in your > board config file you can use your company network server to get your file. > The ip,gateway,netmask still are gotten from the dhcp reply. I can see no need for this. If I understand you correctly, you want to use DHCP to configure the network interface, yet download by TFTP from a different server. Did you thy something like this: => setenv my_bootfile "/tftpboot/foo" => setenv my_tftpserver XXX.XXX.XXX.XXX => saveenv => setenv autoload no => dhcp => setenv serverip $(my_tftpserver) => tftp 200000 $(my_bootfile) Or what exactly is your problem? Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd(a)denx.de To program is to be.

2 1

[U-Boot-Users] Relocation on MPC852T AdderII
by Raghu 30 Jul '03

30 Jul '03

Hi, Working on u-boot for AdderII ( MPC852T ) I am able to get SMC1 up ( CPU_CLK issue ). Now the code is copied into RAM and is executing from RAM. But it is not able to branch to func "board_init_r" I have confirmed using BDI2000 the the code for "board_init_r" is actually present at that RAM location. The branch is done in func "clear_bss" cpu/mpc8xx/start.S file. But the PC always jumps to "trap_init" function. I am using the "u-boot.lds" file from FADS board. I have attached the assembly listing and dump from BDI. Regards, Raghu. __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com void board_init_r (gd_t *id, ulong dest_addr) { fe003924: 94 21 ff d8 stwu r1,-40(r1) fe003928: 7c 08 02 a6 mflr r0 fe00392c: 48 00 00 05 bl fe003930 <board_init_r+0xc> fe003930: bf 61 00 14 stmw r27,20(r1) fe003934: 7f c8 02 a6 mflr r30 fe003938: 90 01 00 2c stw r0,44(r1) fe00393c: 80 1e ff f0 lwz r0,-16(r30) DECLARE_GLOBAL_DATA_PTR; BDI>md 0x007bf924 007bf924 : 9421ffd8 7c0802a6 48000005 bf610014 .!..|...H....a.. 007bf934 : 7fc802a6 9001002c 801efff0 7c7d1b78 .......,....|}.x 007bf944 : 7fc0f214 80030004 807e8064 60000001 .........~.d`... 007bf954 : 7c9f2378 901d0004 837d0000 48005ab5 |.#x.....}..H.Z. 007bf964 : 811e8070 813e806c 80080000 817e8068 ...p.>.l.....~.h fe002380 <clear_bss>: fe002380: 80 6e 80 20 lwz r3,-32736(r14) fe002384: 80 8e 80 24 lwz r4,-32732(r14) fe002388: 7c 03 20 40 cmplw r3,r4 fe00238c: 41 82 00 18 beq- fe0023a4 <clear_bss+0x24> fe002390: 38 00 00 00 li r0,0 fe002394: 90 03 00 00 stw r0,0(r3) fe002398: 38 63 00 04 addi r3,r3,4 fe00239c: 7c 03 20 40 cmplw r3,r4 fe0023a0: 40 82 ff f4 bne+ fe002394 <clear_bss+0x14> fe0023a4: 7d 23 4b 78 mr r3,r9 fe0023a8: 7d 44 53 78 mr r4,r10 fe0023ac: 48 00 15 79 bl fe003924 <board_init_r> BDI>rd GPR00: 00000000 0075bf78 00000000 fe01a000 GPR04: 007d6000 007d6000 00000010 007d5ffc GPR08: fe019ffc 0075bf98 007bc000 fe018000 GPR12: 00000000 30100010 007dc000 027bc000 GPR16: 00191410 001000a0 10001084 02010000 GPR20: 22440800 00000001 10000080 80008462 GPR24: 0075bf98 007bc000 0075bfc4 00000000 GPR28: 0075bf78 fa202ec0 007dc0f0 00000001 CR : 28000002 MSR: 00001002 BDI> U-Boot 0.4.0 (Jul 30 2003 - 18:36:04) CPU: unknown MPC860 (0x08000003) at 48 MHz: 4 kB I-Cache 4 kB D-Cache FEC pres ent Board: AdderII DRAM: 8 MB Top of RAM usable for U-Boot at: 00800000 Reserving 272k for U-Boot at: 007bc000 Reserving 384k for malloc() at: 0075c000 Reserving 60 Bytes for Board Info at: 0075bfc4 Reserving 44 Bytes for Global Data at: 0075bf98 Stack Pointer at: 0075bf78 New Stack Pointer is: 0075bf78

2 1

[U-Boot-Users] [mpc8245 Portx problem]
by 배장식 30 Jul '03

30 Jul '03

I have tried to configure PortX for use of memory space 0x7000_0000. I have modified MCCR4[EXTROM] to enable entened ROM. but i can't accessed address 0x70000000 ... i find something worng in include/config_Sandpint8245.h according to define BATs in config_Sandpint8245.h not allocate BATs for address 0x7000000 , so i try change BAT1 for extended rom i modify ppcboot code to blow list 1. 0x40000000 used by initial stack , until sdram init....(BAT1 allocation) 2. command/board.c : board_init_r () this function use stack...in ram so no more need 0x40000000 3. my added code to BAT1 realloction for 0x70000000.. void move_bat1 (void) { mtspr (IBAT1L, (0x70000000 | BATL_PP_10 | BATL_CACHEINHIBIT)); mtspr (IBAT1U, (0x70000000 | BATU_BL_256M | BATU_VS | BATU_VP)); mtspr (DBAT1L, (0x70000000 | BATL_PP_10 | BATL_CACHEINHIBIT)); mtspr (DBAT1U, (0x70000000 | BATU_BL_256M | BATU_VS | BATU_VP)); __asm__ __volatile__("eieio"); __asm__ __volatile__("isync"); __asm__ __volatile__("sync"); } 4. call move_bat1 at board_init_r ...... but...board not working.....

1 0

[U-Boot-Users] PATCH : Allow dhcp to get IP address from and keep other env data .
by Woodruff, Richard 30 Jul '03

30 Jul '03

Hello, This small patch adds the conditional DHCP_IP_ADDR_ONLY . This allows someone to use the dhcp command to load a file on a network where you DON'T have access to the dhcp server, but would like to use it to have fast downloads of development kernels or other files. Prior to this patch the the reply packet would trash your environment settings for bootfile and serverip will not be used when issuing the dhcp command. By adding the CFG_DHCP_CMD, along with DHCP_IP_ADDR_ONLY in your board config file you can use your company network server to get your file. The ip,gateway,netmask still are gotten from the dhcp reply. Regards, Richard W.

2 1

RE: [U-Boot-Users] heap location (PXA)
by Woodruff, Richard 29 Jul '03

29 Jul '03

Hello, The memory map for ARM is not as documented in the u-boot README (which is still fairly powerpc centric in several spots). I can't say that it has really bothered me one way or the other as what is there is functional. BOTH the stack and heap are currently located above the relocated text area (as is the board info structure). - armboot_real_end's value of deadcode is really only a place holder until the variable is initialized after relocation in cpu.c. Fixing the memory map to match would be nice from a consistency standpoint, but I'm not sure if there is any great functional gain from it. If there is I'd like to hear about it also, and then perhaps then would it be worth the effort to switch it. The main gain in the "overall" scheme which is used on PPC seems to be its selective relocation allowing for a very small dynamic memory footprint, not so much in its arrangement. Of coarse small is all relative to what you have, but these days it seems to be less a concern on 32bit systems. The map I use looks something like. --------------------------- 0x11f6df84 | | Heap for malloc |- Environment |- nand struct --------------------------- 0x11f3DF84, malloc_start | - abort stack 3 words | - u-boot globals (r8) | Stack | --------------------------- 0x11f1df84, _armboot_end | | Text | | |--------------------------- 0x11f00000, Regards, Richard W. -----Original Message----- From: Nemec, Bernhard [mailto:Bernhard.Nemec@jaeger-toennies.com] Sent: Monday, July 28, 2003 3:25 AM To: u-boot-users(a)lists.sourceforge.net Subject: [U-Boot-Users] heap location (PXA) Hi, I'm porting u-boot 0.4.0 to a custom PXA255 board similar to the CSB226, of which I used the configuration as a starting point. What I'm confused about ATM is _armboot_real_end, which is used for heap initialisation with mem_malloc_init() in lib_arm/board.c. 1 - _armboot_real_end has the value 0x0BADC0DE, which is not in RAM, but in FLASH range of the PXA. 2 - the heap is supposed to be located *below* u-boot, not above, since u-boot itself gets relocated to the upper end of RAM. Therefore I would propose to change mem_malloc_init (_armboot_real_end); to mem_malloc_init ( _armboot_start - CFG_MALLOC_LEN ); in start_armboot(). I'm interested in any thoughts on the subject. Thanks, Bernhard

2 1

[U-Boot-Users] u-boot for MPC8266-PCI board
by Thomas Schäfer 29 Jul '03

29 Jul '03

Rune and Yuli, thank you for your replies. I tried out Rune's hints and found the board resetting continously after initialization of the SDRAM. I enabled the debug messages in the SDRAM initialization sequence and found the following memory controller settings: U-Boot 0.4.5 (Jul 28 2003 - 14:18:33) MPC8260 Reset Status: External Soft, External Hard MPC8260 Clock Configuration - Bus-to-Core Mult 3x, VCO Div 2, 60x Bus Freq 33-100, Core Freq 100-300 - dfbrg 0, corecnf 0x08, busdf 3, cpmdf 1, plldf 0, pllmf 1 - vco_out 264000000, scc_clk 66000000, brg_clk 66000000 - cpu_clk 198000000, cpm_clk 132000000, bus_clk 66000000 CPU: MPC8260 (HiP4 Rev 14, Mask A.0(A) 2K25A) at 198 MHz Board: Motorola MPC8266ADS I2C: ready DRAM: memctl->memc_mptpr = 0x00001900 memctl->memc_psrt = 0x00000021 memctl->memc_br2 = 0x00000041 memctl->memc_or2 = 0xff001080 memctl->memc_psdmr = 0xeb6eb493 ramaddr = 0x00000008 memctl->memc_psdmr = 0xcb6eb493 memctl->memc_psdmr = 0xdb6eb493 memctl->memc_psdmr = 0xc36eb493 SDRAM configuration read from SPD Size per side = 16MB Organization: 1 sides, 2 banks, 9 Columns, 11 Rows, Data width = 64 bits Refresh rate = 33, CAS latency = 3 Total size: 16 MB In the u-boot-0.3.0 source tree I found that the memory controller was programmed with hard-set values. Trying these values I found that u-boot started to the prompt without problems. The settings are listed below: U-Boot 0.4.5 (Jul 28 2003 - 16:44:07) MPC8260 Reset Status: Software Watchdog, External Soft, External Hard MPC8260 Clock Configuration - Bus-to-Core Mult 3x, VCO Div 2, 60x Bus Freq 33-100, Core Freq 100-300 - dfbrg 0, corecnf 0x08, busdf 3, cpmdf 1, plldf 0, pllmf 1 - vco_out 264000000, scc_clk 66000000, brg_clk 66000000 - cpu_clk 198000000, cpm_clk 132000000, bus_clk 66000000 CPU: MPC8260 (HiP4 Rev 14, Mask A.0(A) 2K25A) at 198 MHz Board: Motorola MPC8266ADS I2C: ready DRAM: memctl->memc_mptpr = 0x00001900 memctl->memc_psrt = 0x00000021 memctl->memc_br2 = 0x00000041 memctl->memc_or2 = 0xff001080 memctl->memc_psdmr = 0x296eb452 <=> 0xeb6eb493 ramaddr = 0x00000008 memctl->memc_psdmr = 0x096eb452 <=> 0xcb6eb493 memctl->memc_psdmr = 0x196eb452 <=> 0xdb6eb493 memctl->memc_psdmr = 0x416eb452 <=> 0xc36eb493 SDRAM configuration read from SPD Size per side = 16MB Organization: 1 sides, 2 banks, 9 Columns, 11 Rows, Data width = 64 bits Refresh rate = 33, CAS latency = 3 Total size: 16 MB FLASH: 8 MB *** Warning - bad CRC, using default environment In: serial Out: serial Err: serial Net: FCC2 ETHERNET Hit any key to stop autoboot => Playing with the parameters I found that the problem is located in the SDAM bits of the PSDMR register which have to be programmed for my board as shown in the second setting. Any ideas? I have another question according the CIP and BMS settings of the HRCW. They are both set to '1' which means that exceptions are vectored to 0x000n_nnnn and boot memory region is located at 0x0000_0000. I tried out to set those bits to '0', it didn't work. Why? Best regards, Thomas Schäfer ____________________________________ GIGA STREAM GmbH Konrad-Zuse-Str. 7 66115 Saarbrücken Tel.: + 49 (0)681 / 95916 - 203 Fax: + 49 (0)681 / 95916 - 100 E-mail: tschaefer(a)giga-stream.de

3 2

[U-Boot-Users] Using SMC1 UART on MPC852T ( AdderII board )
by Raghu 29 Jul '03

29 Jul '03

Hi All, I am trying to port u-boot on AdderII card( analogue-micro ) hosting MPC852T. Is this already done this before ?? I am trying to configure SMC1 port as a console to get boot up messages. I have defined #define CONFIG_8xx_CONS_SMC1 1 I have a assembly listing, I am using BDI to single step. It complets "serial_init" function and calls "display_options" func. This in turn calls .. printf() -> puts() -> serial_putc(). In the serial_putc func, it goes into an endless loop, here. while (tbdf->cbd_sc & BD_SC_READY) { WATCHDOG_RESET (); __asm__("eieio"); } The assembly listing is as, --------------------------------------------------- fe0145b8: 7c 00 06 ac eieio fe0145bc: a0 0a 00 00 lhz r0,0(r10) fe0145c0: 70 09 80 00 andi. r9,r0,32768 fe0145c4: 40 82 ff f4 bne+ fe0145b8 <serial_putc+0x68> ---------------------------------------------------- Any clues please ?? Warm Regards Raghu. __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com

3 2