August 2003 - U-Boot

[U-Boot-Users] mkimage for DOS
by Dave Westwood 10 Jun '05

10 Jun '05

long shot really, but does anyone have a working executable mkimage for DOS or a dos window in windows (don't flame me for using windows !!)

2 1

[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] what is wrong when calloc return bogus?
by Holger Schurig 06 Nov '03

06 Nov '03

I recently updated from u-boot 0.3.2 to CVS (0.4.5). Now blob stopped working. I tracked this down from device_init() to ListCreate() or NewHandle(). My debug output is: U-Boot 0.4.5 (Aug 15 2003 - 18:26:38) U-Boot code: A3000000 -> A300D4E0 BSS: -> A3024000 DRAM Configuration: Bank #0: a0000000 128 MB Flash: 32 MB 1 2 4 6 7 9 10 d1 d3 l1 n1 n2 memPtr=0badc0e8 n3 hanPtr=0badc108 n4 l2 l3 0badc108 list_t ListCreate (int elementSize) { list_t list; printf("l1\n"); list = (list_t) (NewHandle (sizeof (ListStruct))); /* create empty list */ printf("l2\n"); if (list) { printf("l3 %08x\n", list); (*list)->signature = LIST_SIGNATURE; (*list)->numItems = 0; (*list)->listSize = 0; (*list)->itemSize = elementSize; (*list)->percentIncrease = kDefaultAllocationPercentIncrease; (*list)->minNumItemsIncrease = kDefaultAllocationminNumItemsIncrease; } printf("l4\n"); return list; } Target is an Intel PXA255

3 2

[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

Re: [U-Boot-Users] i2c for mpc107 bridge
by Wolfgang Denk 10 Sep '03

10 Sep '03

Dear Gleb, in message <20030828123944.GA10453(a)nbase.co.il> you wrote: > > > Can you please submit this as a proper patch? See the corresponding > > section in the README for instructions. > > > No problem. > > Attached patch is against u-boot-0.4.0. I can't download CVS download is to slow. > I hope it will apply. It does not, but I'm willing to fix this (if you cannot or do not want to prepare a patch against a never version). If the public CVS server is too slow please remember that nightly CVS snapshots are available for FTP. Main problem: can you please add a GPL header to your new files and resubmit the patch? 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 difference between a man and a machine is that a machine is quiet when well oiled.

2 2

[U-Boot-Users] Motorola PPC8270
by Matias Sundman (TB/EAB) 01 Sep '03

01 Sep '03

Hi, I have now started my work on porting u-boot to a Motorola PPC8270 based board. I wonder if anybody has already made a CPU (PPC8270) port? I guess the PPC8260 is pretty close to the PPC8270, perhaps I can use that as my guiding principle im my coming efforts? P.S. In the top level README file, the C - code on how to port u-boot made me LOL! //Matias

3 2

[U-Boot-Users] Patch: PCI mode indication for PQ2FADS-ZU
by Yuli Barcohen 31 Aug '03

31 Aug '03

Hi, According to the MPC8260 User's Manual, PCI_MODE signal should be reflected in SCCR register, and local bus pins configuration is taken from HRCW and appears in SIUMCR. For some reason it does not work this way, so the only possibility to detect if the board is configured in PCI mode is to check the BCSR. The attached patch sets SCCR and SIUMCR according to the BCSR. -- ======================================================================== Yuli Barcohen | Phone +972-9-765-1788 | Software Project Leader yuli(a)arabellasw.com | Fax +972-9-765-7494 | Arabella Software, Israel ======================================================================== Index: board/mpc8260ads/mpc8260ads.c =================================================================== RCS file: /home/CVS/u-boot/u-boot/board/mpc8260ads/mpc8260ads.c,v retrieving revision 1.1.1.5 retrieving revision 1.9 diff -p -u -r1.1.1.5 -r1.9 --- board/mpc8260ads/mpc8260ads.c 6 Aug 2003 17:03:01 -0000 1.1.1.5 +++ board/mpc8260ads/mpc8260ads.c 7 Aug 2003 09:22:32 -0000 1.9 @@ -35,6 +35,7 @@ #include <common.h> #include <ioports.h> #include <mpc8260.h> +#include <asm/m8260_pci.h> #include <i2c.h> #include <spd.h> #include <miiphy.h> @@ -237,6 +238,7 @@ int board_pre_init (void) long int initdram (int board_type) { + vu_long *bcsr = (vu_long *)CFG_BCSR; volatile immap_t *immap = (immap_t *) CFG_IMMR; volatile memctl8260_t *memctl = &immap->im_memctl; volatile uchar *ramaddr, c = 0xff; @@ -252,27 +254,41 @@ long int initdram (int board_type) immap->im_siu_conf.sc_ppc_alrh = 0x01267893; immap->im_siu_conf.sc_tescr1 = 0x00004000; +#if CONFIG_ADSTYPE == CFG_PQ2FADS + if ((bcsr[3] & BCSR_PCI_MODE) == 0) { /* PCI mode selected by JP9 */ + immap->im_clkrst.car_sccr |= M826X_SCCR_PCI_MODE_EN; + immap->im_siu_conf.sc_siumcr = + (immap->im_siu_conf.sc_siumcr & ~SIUMCR_LBPC11) + | SIUMCR_LBPC01; + } +#endif /* CONFIG_ADSTYPE == CFG_PQ2FADS */ + memctl->memc_mptpr = CFG_MPTPR; #ifdef CFG_LSDRAM_BASE - /* Init local bus SDRAM */ - memctl->memc_lsrt = CFG_LSRT; + /* + Initialise local bus SDRAM only if the pins + are configured as local bus pins and not as PCI. + The configuration is determined by the HRCW. + */ + if ((immap->im_siu_conf.sc_siumcr & SIUMCR_LBPC11) == SIUMCR_LBPC00) { + memctl->memc_lsrt = CFG_LSRT; #if CONFIG_ADSTYPE == CFG_PQ2FADS /* CS3 */ - memctl->memc_or3 = 0xFF803280; - memctl->memc_br3 = CFG_LSDRAM_BASE | 0x00001861; + memctl->memc_or3 = 0xFF803280; + memctl->memc_br3 = CFG_LSDRAM_BASE | 0x00001861; #else /* CS4 */ - memctl->memc_or4 = 0xFFC01480; - memctl->memc_br4 = CFG_LSDRAM_BASE | 0x00001861; + memctl->memc_or4 = 0xFFC01480; + memctl->memc_br4 = CFG_LSDRAM_BASE | 0x00001861; #endif /* CONFIG_ADSTYPE == CFG_PQ2FADS */ - memctl->memc_lsdmr = CFG_LSDMR | 0x28000000; - ramaddr = (uchar *) CFG_LSDRAM_BASE; - *ramaddr = c; - memctl->memc_lsdmr = CFG_LSDMR | 0x08000000; - for (i = 0; i < 8; i++) { + memctl->memc_lsdmr = CFG_LSDMR | 0x28000000; + ramaddr = (uchar *) CFG_LSDRAM_BASE; + *ramaddr = c; + memctl->memc_lsdmr = CFG_LSDMR | 0x08000000; + for (i = 0; i < 8; i++) + *ramaddr = c; + memctl->memc_lsdmr = CFG_LSDMR | 0x18000000; *ramaddr = c; + memctl->memc_lsdmr = CFG_LSDMR | 0x40000000; } - memctl->memc_lsdmr = CFG_LSDMR | 0x18000000; - *ramaddr = c; - memctl->memc_lsdmr = CFG_LSDMR | 0x40000000; #endif /* CFG_LSDRAM_BASE */ /* Init 60x bus SDRAM */ Index: include/configs/MPC8260ADS.h =================================================================== RCS file: /home/CVS/u-boot/u-boot/include/configs/MPC8260ADS.h,v retrieving revision 1.1.1.5 retrieving revision 1.11 diff -p -u -r1.1.1.5 -r1.11 --- include/configs/MPC8260ADS.h 6 Aug 2003 17:03:02 -0000 1.1.1.5 +++ include/configs/MPC8260ADS.h 7 Aug 2003 09:22:32 -0000 1.11 @@ -206,6 +206,8 @@ /* * Miscellaneous configurable options */ +#define CFG_HUSH_PARSER +#define CFG_PROMPT_HUSH_PS2 "> " #define CFG_LONGHELP /* undef to save memory */ #define CFG_PROMPT "=> " /* Monitor Command Prompt */ #if (CONFIG_COMMANDS & CFG_CMD_KGDB) @@ -247,7 +249,7 @@ #define CFG_IMMR 0xF0000000 #define CFG_BCSR 0xF4500000 #define CFG_SDRAM_BASE 0x00000000 -#define CFG_LSDRAM_BASE 0xD0000000 +#define CFG_LSDRAM_BASE 0xFD000000 #define RS232EN_1 0x02000002 #define RS232EN_2 0x01000001 @@ -255,6 +257,7 @@ #define FETH1_RST 0x04000004 #define FETHIEN2 0x01000000 #define FETH2_RST 0x08000000 +#define BCSR_PCI_MODE 0x01000000 #define CFG_INIT_RAM_ADDR CFG_IMMR #define CFG_INIT_RAM_END 0x4000 /* End of used area in DPRAM */ @@ -326,6 +329,10 @@ #define CFG_TMCNTSC (TMCNTSC_SEC|TMCNTSC_ALR|TMCNTSC_TCF|TMCNTSC_TCE) #define CFG_PISCR (PISCR_PS|PISCR_PTF|PISCR_PTE) #define CFG_RCCR 0 + +#if CONFIG_ADSTYPE == CFG_8266ADS +#undef CFG_LSDRAM_BASE /* No local bus SDRAM on MPC8266ADS */ +#endif /* CONFIG_ADSTYPE == CFG_8266ADS */ #if CONFIG_ADSTYPE == CFG_PQ2FADS #define CFG_PSDMR 0x824B36A3

2 1

[U-Boot-Users] Open patches ?
by Wolfgang Denk 30 Aug '03

30 Aug '03

Ummm... I'm afraid I lost my list of open U-Boot patches. The only open issue I can remember is Bill Hargen's "patch for MPC824x I2C driver" of 11 Aug 2003 (which I did not look into as i might be obsoleted by Gleb Natapov's new implementation, which is just missing a GPL note). Please drop me a note if you submitted any patches that did not make it yet into the CVS tree (current CVS tag is U-Boot-0_4_7). Please make sure to include the subject and/or date of your message. 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 Only in our dreams we are free. The rest of the time we need wages. - Terry Pratchett, _Wyrd Sisters_

1 0

RE: [U-Boot-Users] [PATCH] ARM925/OMAP updates and console device chaining.
by Woodruff, Richard 30 Aug '03

30 Aug '03

Hi Wolfgang, I was hoping to get comments on the device chaining aspect. I put this together quickly with that more central in my mind. So ...? (later I did notice that there were 4 c++ comments in there also). I can break up the 925/omap bits. I have a couple critical fixes to add anyway. Best Regards, Richard Woodruff > -----Original Message----- > From: Wolfgang Denk [mailto:wd@denx.de] > Sent: Friday, August 29, 2003 5:07 PM > To: Woodruff, Richard > Cc: 'u-boot-users(a)lists.sourceforge.net' > Subject: Re: [U-Boot-Users] [PATCH] ARM925/OMAP updates and > console device chaining. > > > In message > <FD2AC9A020DDD51194710008C7089B200BEE2301(a)dlee17.itg.ti.com> > you wrote: > > > > This patch adds a few updates for the ARM925/OMAP boards. > > - DSP idle routine (I call from board specific code). > > - cache flush implemented so lib_arm/cache.c is not just a place > > holder. > > - header file updates. > > It also adds support for having multiple devices called as > part of your > > console (if you install them). There is also a handy > CCACHE addition to the > > makefile which can speed up compilations a if you have > ccache on your > > machine. ... I have also included the nand fix which I > submitted a little > > while ago. > > Please split into separate (orthogonal) parts. > > Please make extensions (multiple device support) configurable. > > Also: > > Please do not use C++ comments. > > Please use proper indentation (TABs). > > Please do not add trailing white space. > > Please exclude the ccache part, as this tool is not > commonly available. > > > Patch rejected. > > > 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 > "A witty saying proves nothing." - Voltaire >

2 1

[U-Boot-Users] [PATCH] ARM925/OMAP updates and console device chaining.
by Woodruff, Richard 30 Aug '03

30 Aug '03

Hello, This patch adds a few updates for the ARM925/OMAP boards. - DSP idle routine (I call from board specific code). - cache flush implemented so lib_arm/cache.c is not just a place holder. - header file updates. It also adds support for having multiple devices called as part of your console (if you install them). There is also a handy CCACHE addition to the makefile which can speed up compilations a if you have ccache on your machine. ... I have also included the nand fix which I submitted a little while ago. Regards, Richard Woodruff.

2 1

[U-Boot-Users] Fix TI Innovator/OMAP1510 pin configs
by George G. Davis 29 Aug '03

29 Aug '03

Greetings, The attached patch fixes a minor problem in the TI Innovator/OMAP1510 pin configs. This patch is required to fix Linux MMC driver failures since the Linux MMC driver expects the OMAP1510 pin config to be setup properly by the boot firmware. I'm merely passing on this change that we made to the rrload boot firmware long ago. I've tested the Linux MMC driver on the TI Innovator while using u-boot with this fix applied and the MMC driver now works as expected. TIA! -- Regards, George Index: board/omap1510inn/platform.S =================================================================== RCS file: /cvsroot/u-boot/u-boot/board/omap1510inn/platform.S,v retrieving revision 1.2 diff -u -r1.2 platform.S --- board/omap1510inn/platform.S 16 Jul 2003 21:53:02 -0000 1.2 +++ board/omap1510inn/platform.S 20 Aug 2003 00:59:42 -0000 @@ -84,6 +84,9 @@ ldr r0, REG_FUNC_MUX_CTRL_C ldr r1, VAL_FUNC_MUX_CTRL_C str r1, [r0] + ldr r0, REG_FUNC_MUX_CTRL_D + ldr r1, VAL_FUNC_MUX_CTRL_D + str r1, [r0] ldr r0, REG_VOLTAGE_CTRL_0 ldr r1, VAL_VOLTAGE_CTRL_0 str r1, [r0] @@ -352,9 +355,9 @@ VAL_PULL_DWN_CTRL_1: .word 0x2e047fff VAL_PULL_DWN_CTRL_2: - .word 0xffd7d3e6 + .word 0xffd603a6 VAL_PULL_DWN_CTRL_3: - .word 0x00003f03 + .word 0x00003e03 VAL_VOLTAGE_CTRL_0: .word 0x00000007 VAL_TEST_DBG_CTRL_0:

2 1

[U-Boot-Users] Submitting patch for TI OMAP 1610 Board
by Gupta, Kshitij 29 Aug '03

29 Aug '03

hi, Attached is a patch file for TI OMAP 1610 Board. The attached file is zipped tar file which can be unzipped using (tar -jxf patch-final-omap1610-0.4.6.tar.bz2) command. And then applied to the u-boot-0.4.6 source tree. warm regards -kshitij

2 1

[U-Boot-Users] Steps performed by Uboot!
by deya privi 29 Aug '03

29 Aug '03

Hi I am new to this list. I want to use U-boot for my Intels Xscale PXA255. To start my linux OS, I want these things to be performed. Can anyone tell me what out of these steps, U-boot can perform for me? a. Initialize the CPU Clock. b. Initialize the on chip Serial UART for debug messages. c. Initialize and set up the SDRAM. d. Check and report the FLASH and SDRAM sizes. e. Check and report the available Peripherals. f. Copy the rest of the BIOS to SDRAM and transfer control g. Invoke the OS and transfer control Thanks in advance for any help! Regards, Deya. ________________________________________________________________________ Yahoo! India Promos: Win TVs, Bikes, DVD players & more! Go to http://in.promos.yahoo.com

2 1

[U-Boot-Users] problem of u-boot make
by yanzhijun 29 Aug '03

29 Aug '03

hi,can you see where is the problem? my compiled environment is red hat linux ,and i have installed a arm cross compiler in my machine ,and export $PATH.But now when i want to compile u-boot with cpu arm ,it troubled me .first i do like this : #make lubbock_config then: #make here are some of the informations : make[1]: `.depend' is up to date. make[1]: Leaving directory `/home/yzj/u-boot-0.4.0/post/cpu' make[1]: Entering directory `/home/yzj/u-boot-0.4.0/examples' make[1]: `.depend' is up to date. make[1]: Leaving directory `/home/yzj/u-boot-0.4.0/examples' make[1]: Entering directory `/home/yzj/u-boot-0.4.0/tools' gcc -Wall -pedantic -I../include -I.. -DTEXT_BASE=0xa3000000 -DUSE_HOSTCC -O -c -o img2srec.o img2srec.c /tmp/cc1TzDSI.s: Assembler messages: /tmp/cc1TzDSI.s:390: Warning: Bad .section directive: want a,w,x in string /tmp/cc1TzDSI.s:390: Error: Rest of line ignored. First ignored character is `M'. /tmp/cc1TzDSI.s:762: Warning: Bad .section directive: want a,w,x in string /tmp/cc1TzDSI.s:762: Error: Rest of line ignored. First ignored character is `M'. make[1]: *** [img2srec.o] Error 1 make[1]: Leaving directory `/home/yzj/u-boot-0.4.0/tools' make: *** [subdirs] Error 1 I don`t know what is the problem. I want to compile with arm-linux-gcc ,while it shows gcc ? can anyone tell me ? thanks !

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

Re: [U-Boot-Users] i2c for mpc107 bridge
by gleb＠nbase.co.il 28 Aug '03

28 Aug '03

Mesage was to big. Trying one more time. On Thu, Aug 28, 2003 at 02:21:14PM +0200, Wolfgang Denk wrote: > In message <20030828094209.GA9003(a)nbase.co.il> you wrote: > > > > I wrote my own simple driver (attached) that does work from flash. May be > > somebody needs it :) > > Can you please submit this as a proper patch? See the corresponding > section in the README for instructions. > No problem. Attached patch is against u-boot-0.4.0. I can't download CVS download is to slow. I hope it will apply. CHANGELOG: * Patch by Gleb Natapov, 28 Aug 2003: new I2C driver for mpc107 bridge. Now works from flash. begin 644 i2c.diff.gz M'XL(",?U33\``VDR8RYD:69F`.U]:WL:1Y;P9_0K:CP3!RQ`(,N)+<<98R0Y M;'1;D#/)[CL/3P.-U&.@V6ZPI)WDO[_G5K>FN5E*,KL;'E^@NRZG3ITZMSIU M:A`-AZHR3\Y5Y4[UI_-N-(EFU;ZJ_*@&\60VH-=WJA<.>O/K[E>UYR&\G%=Z M<3RKU*H'U=H>5-H;3_LO]P_N]@9)]"E,TKUHOX]_ZYFRU7'R:4WYG4JELDW[ MA?U:[7FE]E5E?U_MUP[K+P\/]JLU_5&[M>>UVL[N[NZV<!3JK[ZN56IU^*-J M^X>U&OSQVH5^=]Z^595ZN;Y_@`_*-?7V[4YE[]E#/CL517]5,Y[>)]'US4R] M56?Q+$[B45!6]5>O7NDB#_CL[53^'$WZH_D(a)5-_TX_$XGE1OOMVIX./A(!RJ MYL7Y2>M]][M&^ZC;VF^ZQ0$]5-8\>0)/NN'=-$YFU9LGF1?T!)[-)]BL@K:. MWKVOV0='Q^\^O,<2>\_443B,)J$*U#CH)[&:Q6J>PL^)BJ>S*)X$(Q5,IZ.H M'^"ORBBX#Q,U3:+)3`WGDSX^+*MH2-B+H9W;(%73($W#`38UNPFQ=S6*>DF0 MW*O!'&I>*Z3V*!A%_TV-5@'"(19-J#HU-8E-\VH:0V_8*S5;AI(1])'$L[`_ M2U5P'423=*;ZP6A$;<^@O<8HC=6`1D;-(1S7H[@'H_D4)%'0&X7P+)BIFW@T M2.FU`"V=5;$:3A@WHJY:9\<7'ZY4L7D"$_0?>P<E^^ZRW3J_`ARH(J*JR\@I MV>\[E70&`^TK?%Y\9IZ75+%_$R3J65E5J]72:YZ0Q8]J(40X$X!1Q.81K9M% M6MPS/<TG:70]@>%(a)E^_N9^%5_.,XFJDWJO8ZOQ"^QH)+BC"@5&@^7-?,?'@\ MGL[N.[-XNJ(H@]7N?UI1!MZN!0K+K(2)"YS,1VL`.@M2P#.4;@P&29BF4I16 M22><J=X]$1G.PG4XZX;S<:\'``A-P\1T6YJN0Z(?=864VH_GHP&P<B'`T;T* M/@71B&EP88F456\^D\40\5J`M1@,/@6367!--9!2F=(5++8`?B?!.`30#_$1 M]!B,DC`8W,.@X&T27D<X+FEJ``(F3"=?`ND'GZ@Y@&P4!P-`PC")QVH<CN/D M7M90F5=)Q$OD-KC'_ZDE=U7CFC=]CJ>C<!P"Q0ZHMQ8*-.CM%N#'WF#.)C`, M`/0VFMW$\QG#I:#3$%;L##!#-8/1?1JEC,860=`+<=!I**/.+F<8K#\%V-M- M-*"^<&2&$1RUSK]WF9HBI@:(#_L!\CY&XO?!S6@>5-)IV(^&41^9%'*>R4=" M"37F4$&9<-A-YI-9-`Z[@/0R#3\%&1*ZCU5ZH^F!V0?2GN`@TZ7EFF%`K`TQ M1B,(QZ`9X(S-9]$(QANF,FVJ-XK['QEK;9)CD_BV[)$K#,UVK`8PH.?[>Q^I MYVH*H[R"]F.D/S6[C560\'0O5LD([_UJJGEFWMIZ3[-E@-`K*[Q#SN87S2)2 M%;W7&N$[E0)\%'V\`E"EM+3QQ?E8W_I"\V7_R:=@M)QY:Q[>N&SE,FSB+@V' M&"^3^!K6,S/]8=`/51'JEG`F:.Z1!9'X^Q0A!?3N-0>A>=(D(a)V)\.H5)9('M M4'NJBE$UK)9I&92P8-#O([?#9I@"S0+OS5,5:3B$-K183HF^8>SS,&4N@1`" M+YJI>,@R&N!FRJ:EW1_!_T1!KNJBB8;PH)S5B_W/)\(G"+AA/!K%M[`0#JE5 MQ13X9:K2$;*R@+DVOR.HD_D49G2"[&'`CXU.HW4*''Z6$V34&Z,<XO#3T+); M6'3`$'O4<SC00(5IA,/LXT)423`+Y7ET'<V@XV$TPGZ'2?A?\W#2OU=I`!P3 M5[<NJ_L"!!H5:#P'#:?'DX^3'@Z171H4]4%$P%M@7@.-3^2%'5B(,(,9MECT MY2>BC<E=*2YZ?G7<;G^XO.J>71P=`_[`.)F9$JS#3#.Z"VA#_X024%WZ3.D_ M6A4%F-@0?O=&4<H3*<A'O=%(.E0>RUH>.E,"T_N$YF/XA,95L"K6&S4U';2$ MY$12#:-$5$)B?ILP36@'\-X+4D-)R/*_'`,'!;8Q1]T4B1P@'`#-]$!R*:"P M.`$Y.AG0!.)(#KD9&%@`%2>5_PY!IZ9%@J`EX6R>3%"'Q34'Q`G**E7`@:$" MF663P"=+B/D%]NER]")RGZ75%4Y,@774XA.?%@Z1<D`X`V\?J.,/9^_>-=K_ M;_*$VBLPL$020`\7;7SXB\8W#"D:`,$:]45P9H>"#]135;M[N1J&LE<]FE#+ MATI],8"Z7]P!.(;V/%9=8LK->[@!_$U2Y&Y"9A3($5R%QJP[U+:`^\7)6-W& MR4>>+-7@R</J(!>#^6BV;#VK(A@RI#;%I+G@6ITG":A'H_LR-_8I"LP*+;'. M(`3++,2VC&W$P'ENJ/4P2&-B;9:">-$!=>CVLA11SBS^$J#X>;TLF.25;HA) M6OL3-=?YT&P>=SIKJ(D7!')X>H@HW(R<<#9@?=R&\#\-Q2DM74-Y*DZ"XE(F MA>PZD`)44LV28)(&8I/&$]"TSQH=8&;='\]:5X1:^=UN_F`$DZ.PPH)_!ZH/ M/:;J$1J?;%:.XP$K]521406J_626Q*/4BIL]MSSWT3?Z\^Q^&I)PM'!2$92' MM%RDG+L@2):&(N(&X:>H+PI9,`N\2ID*^%XA!>=5'@'"I!I\O88A0RVJ070* MB()I3,)^"*BE"KWY<!BN[(I+4.&4S2R<N_.+;N?JXK(L1@"2'BPU?*0"%,V# M''046`QQO8UJ(%^%5:NQ#)H=<F=^2+RW;%>=@@9!=K(^`$(BL)"VCSM7C?95 MV4@2Y/PXQ=%DSNH!=!W>@36%$YP/]4(;P<8M+`KM0=QURJCB.O&,\K=[U6Z< M=QK-J];%.9>`VO+:%_R:ZG)?&O*2MZ28AQ/YQ:*?I]SI&F>)^T02<&K25)1= M!'$QQ+]5';I9W6$93%WN^3_K?W\MWC-5)[9P99`^"\>@7Y)Q"GR[$B3Q?#(0 M#=;E]#W@HQ_%`93$L[@?CWA)#LF\GF$[LY1,213SZ"?C=8+S,H[`$(^1V['Y M"EKP!/48MC1=9I3&=J7HU8/\B%93?S8'$N=5=#\#M804:;&,`7V@;B@T^*%W M68>B_^%*%4>`*$YZ6$:J&6U=.R1HG"`UQJR/C((9>^K8NM9.B005-M#D`W<8 MGL6N^];\BKF+90W(/Z9A,--EW*&C8C4CY7D6?!0N"07NL18:G23H$I*6*!B@ M2\)@ZTOXH;T6J-7U`I"/\!W*X3C8::=.X_@C\@JAJ&3&3"T4I6U.OA,4I$)H M:C@*KL$J\G0]8^,_05)^0I/U!,GU"<U..(GGUS>,J>$H[+/`QO;"M(PC`VT\ MC5]K7P[8M-=17^;3GRB4'2G,:M2/0M1?T$7"4@7^!Y[5GUD%4_BM)E2MZF>7 MR7P\OM=+9/_%U[Q(6">#UMXPOW,DHPAU7*@1EZ7"*"2^5?LOOB(--%=^%X`, MP9P$%EI_K2+US1OD$?!M=Y?K>*!$?X=R^KNJ*%J]F3(U+&/6.;WWE!K@B+($ MBL+XB+U97J;J:M=A5%[K969+FAL1\WFM1^MI.UU?W?'T'9\I:PU::XF6.4"' M1O?)1]XO&;7(*CKXZL^XP(9D/(G0`U;D<C,QFSUMG'3%E):TLVY)[S"*.5'! MGW*HX.E3E?,.=*52CMKGHZ&L%7>O7X&&E'FCQ\.[#13"A+R$_9L05_@R$\/H M34O-C"R4GF8U)T\%]91C;V3L"DMA2UZL&)0*1V!5$G`+,FR1XC4.V#SXFS9F M->-#[A!HAN,H=BQ/6"S-V$U;$#W1\MUWZ$(`EC4?"3?$5EBY@MJ:ZZ<S@*UJ M^O<=N)Y&-D1?ABL*L#NN*'UJ?[;K",_H1.P%D%J.,V80#;!C$%(A6N78/#JD MN%-FA##R>)YR56^B>_?,RP6TP(77-;K7<9?,(O$XC?"8[)26?<TWRVW6,9OU MO(84=$^5&)*X#0:;&5M76AQK/@6"'23KPL14Q12S2K(H;\;K,HEOM5Z$\S%/ M0];2-L-MAG-;KKV:73\<@:N9]6,9JEH?M?N8W*WLI0`CIWE;!%/45"HA6T`I MK(H9ZX(SKTUXP`[./(,!7C+OT&S!;(%XU.-L0GD,1=0]5$5SU3BKGUJ7&RJP M6D_A:?Q7,IK_L'O_->U>V3%:-'\URUAG^*HUEJ]::?HJW[K-;C![=JZ9HP5# M5VUNZ<H@$Y@DS\S%%H!<NXB/55H[ZF3,[/:>D;MP/B5>,J8=[(I0L*>+$;,J M8(\R\6A`+;@'+3?6/!C1HAFQYL"N0I,+(a)%5#5D$`?.6S(<CU0P,@`(=1#ZFK M//>E1C'`L;C9F`4(:[=9,FC)<HQNSJ)'HJ5#8[9-;T!;@94'O*P(&F7MY5VI M+*:F_HU*)LU^V4PW]\`K`-A(!HQUD@F'*^P5**5NB8.6HVPYX[*^`04+\3F) MG2TR8V#>PTS*-"TS2QCM'(+CRC/-PK4"=GL3LJ5KE`S2`-'9"N:)^+ZUT3RW M6R,<A$#+&:8DZ1Y_`O9E%!1X_N[#R<G)A]-38-7<B#P[/KN\^@DFO?\)F?@= M4%^I[$R]8E';.#IJXZ\(],(^6NM6]71I59@@XD/#C/OY]^Q[)^I''C=AC[=5 M)V]O(A#%3'EO7,I3/_^LG*<"AF-Y(P'RTL"M'?P%;*]6$GL<4(X(EBT'DLY( MLR-G0X!G5JRCPB`6T]59;RY"%\B\5K(VZ>(HSB^.?S@&V@<3T0%/8"ZI;W1\ ME`,OVV[(%'A7`);'('(8@5FA/IX48`I?X[Z[\]K,^O+73`"YKWUT%UXC?(`A MF&)"'0/D<C4R04/<H>:MP]P1?#8?6<-(UK*.'1V<D,="EOL:/D^)9=WM/)Z% MAT:3:TVH#;,A;]V,9:-BTE8U&(<W6!)#EOAI/!E&UW/<(<_LQ][+;BSK7;3U MU2-&*ON2I$?J2('/_U#S&MQ#+8?,R`9AVD\BBA+`X2K50=5+JWFNNJ@W#R<X M!.`Z)+4D7FE(\JJ+CD5$-,BELF.VWM[$QI7+JBP608OH.IR$M&TH]JIH@2;8 M@\(L=`262/G$!'1):6/2BZMQ'`T&(PE(0R59U$46U9J)&[T,^"8J:548A`[$ M=$&!RAK(@0ID=;!R*JKFHO/;Z0T#%;Q!@H(D37.]&)@J1Q_9H`YK04R0"HV* M*6TBJ]>A)I_[\7101P4E%24W0"BC)&H"*#/GX)GY,O5]5BI?L^Q.9UQ/!Z4X M5-8C+_]LH;YHK&#"4,T)0,45M0$FDR]TFU?=D"BU4%<5S^@@^6W-']P&N1>? M*DQ$#4IG*&-EA9SNH[3;G\Q0)Z8R`H(U'\09I4TH%B?`"7P@;/E)>*NDQF)9 MK1):A%-P!$IE,02=6`G+#5TM2V*T32RU8>)?I,4O!B7#2DBWZW9/6J?'W2Y^ M.VV=PS=DSNS2)2Z<";<M>#&Z#-)K78R"6RWDSG,WS-9,)XM@/W*VD`VV+7A1 MLRP6;D,39,9+J\P(7=3B77E!)8IF69B%H,1?QM/LR)/'9-V@C"QCW<]46\R@ M!>Y-*B:K4ARLA:8_(!?A7L[`C49KB7PX!]DF^WAF5TPX,OL?[8I:QMTW8,S, M3X0K9]:=%B"&*__J_%9;EP]DN4MY+AFFF_)<G,HR&Z&(^2S'W8;E&BQ[3',% MT[4N),3X9M6W8KI(7L+"-F.Z?H6\_C-<=VNVNQ7?_0T9+Q#-9HQW!5^T;-<P M1Y_K9@\29%CN2IY>\]GY)ESW)L>#LX;STG)0[>8/+N,5UHMA$C4RWK&%>#C$ MN/(!&1O4]N>SYAS&?)M$3C3K`FM>J57CMF%$9RH8(5LKU4:AEBC]S91JV^]C MJ-?,3I=IUP8SYQZ'Y4I:H;6E^#.8FP,CHFM+O#;)L6OTDE%]TY.8%_QA0RPC ME#"NI!_:(%R.5G1J6:<>1;Z&>.9*1;C6`PZDT&'B-W-W6/PYB7EN@E[\*92( MQ;(X?9R9#$;09^J"BE/+0>JU;)M3#H\?&]-R+EN#[).`=2(XF<5.+>V;,Q&? MZ!O09$<JLV-8\4=&G482]_>X0H[6QV9B;ELKH?`@(Z&0+ZZR>OJO:RH\4&+\ M*OIUC;Q&@+$X&<C!@4]Q-##$7]8[+&8K%$\F&#J78(V'J>6TOLOJ'W@:X#;` M<TUQ(I%;?#*(a)C&[.Z5S[=?:>91U_14UEJO2:RCQ$*\_A^[@+_1"-7&_8K^7\ MOY4VOL#'K3*^1$WF&@_7DI>Q#D3Q@SG'4FWUH=KN$G5W"_[A*+';*KV/Q3W^ M]91$O=BM+.ZS\.,5'V^WXFULV1)=\%&UP;X+SG+F@"&W9DM*-F#F]L"WL\N= MJ)`V,3CT1+A$(a)U3!,.C?J&%TAVP82AIA7\[$3<B)*>::VA3VP\UD8PH9"N$Z MF(+N,4TBY!E._`55=H)@I!I!^`#%8>GR]W9Q5IY=M/6*SP15I4STFAM\?=6X M4F;C>2.CRP%E,^-+-DNP[OMP1GO]QH`IV0UO+%8=PS=G+Q.?RR#<)>P:1*U. MVVLMLZ4C)5U<^(7-\K=MRKZ7>_9DX:..>$.NM7=AZ2)O.A]3SI+QE[N6U/M\ M?X]6]K3/RQQHH5UGW_ED1%NAT#:XT#MT$;F@],:G*P(?6=")@;N)I".9:QWP MF4`=8\K)OAU%4F!4!N*`*J"OL@BD5E'D\2?MO&2%$!C41:`X>$W.*93`)4_D M9-3F7\VW[77J=3D;Z]0&"ZN9'C2OVJ>J/TM&FR]OQC_%6&%D+&$+PV1A:!+0 M:U>\"'^][LONC#":'8>$PQ$0(H<C-/%GAB,`]CBV;!Q\##DZ'PGV)L"4`*$^ M:X8'T`96_F.[U3&\W43<HVT4WKD=T,%G^(-,W<0R;L"Y>(RL<CQ]JIB1]7J9 MH(PT3C!(Z!;/!:2+$1?O/G3@ST].I(W?=-TV+3S2/N`M[]K2OG00;;;/QNF% M$^+!.+GXOJPU83E$3<(0FN)89*<IKC!-PBF9*K%B^]8JT)Y7EB>'8]#JK\V# MV9WW>W87?-0D30\D:HT1\=J$'O$*Q[,FXCCK18)3(N(L595I%5C:6@8I#A4] M,7L844*D;]KEM;:XY>_N]1_Q7C\7+>)_&*0^I$\-YN=GVA'#3[%HUPH5JM6^ M'I;4-]\@R3C%"`:87#K,^%<LIP[AWSKUDY/7P(>FC!S"H53=F@TERTE_4L]& M>RU)D5+X94NF$MY%&ZH,KO)KO#>D(FJ]-^L878Q(a)^.Q/CBJ+6OT&<M=:*^BQ M"]%TU%%J+&)9NKI1O_QD81RZL\_^+!>O&&>6)UT=K?"SQ`:TB^=ID\UF>)T( M\-B%%7"KUO46<&Y,B(]+8#DJ':^M[H\2I[U(8&?BD028*%V"<>.)&Y`)2'S` M0>+LC>:0E9RZX#:LQW@@9'B!+N';"-;])*8D!AF/M8V%HM04XQ`8L;AD7#,+ M8_[(Q#IT/*L4"54\:YV4C/"21TUXQ,_LP_:/C>^I8,UOH@GE0<LI>>7QX=6/ M_.SS%\ZR%>/,T,J%D\T.8[FN8^U_*U):&S>N(^"-2<=5LO%H:(/>\21II7/! M>4!/L;5%!Z;50-PP4\\"$G7(UT4DL$X:S]N/6UA=M(&!\6K[=TO6EDGI\$Q# MJG;MF#,KK\`AC+E%7^OW3]^0Y,3/<$A/-Q")DKFG8+PRN[LRSKS5GF,?NNCY M+&:PG`^`D,UG`V8;/G#9`!^\PJ5+OE3F`FD\3_KA&BZ@C;G?;(7+HU7+>6$U MUSYO-:]9R>C2VT8"KEW9V&#^PL8W%9O/[HW:QT%FG(7.&H4%;R::3E&F[AGS M1,%#5B[V^=`X+RBS6X#4@=[9_0F=[AX%<C9'BNW)0N?MA4G(9\!1FV:T7Q'3 MI6/6OE(CC&>MS"YX.GS]M;&[5^OC!)%LX%',=S"?Q6.<0$J<EX%&CYF,-W+W M^>?5)21Z<<S:88\.P)1$J(]K.FRM5U9D<,L?=A\-3,*Y3MMV8%CHGMEWUIB3 M,_MZ8N@,DIX5)R1:4\@NK`*@!TL\*ZEE"4/_Q>6?&]DKA6=%\6OO:F*%]:>( MPP*#/3G)UZ\61``:39M*@(4.L_Q?GAOF[*\J-&(TI/]TQ*+=5<N1:1A+[J(H MC]_G<GNI^,BZ7X<LP.6J7X?9^6K-SR'>`?T?N.G+`-<RDG4:H#+*G]0[_XU5 M0/W(UP!7*8"UWT8!M-/T.^A_(*<Y2:9[7G&E(DAGR(ES\6$'J'5]S4=%!4]5 M=11S.@QBM[HXY\'LS=,*[FQ+D$ANS(GM0/98,1N3YJ:!3GTE<2.DE.@:N"]6 ME=2>'`&"23WC&+`V"`-GLTM7D,S$O`&$B;D2W@7B_!H`)OYCX`E'%%/B<?Y\ MO6U1J?T_I-/^)AHM+YNE"JW>,%^ES^IHG&T46DYC*D;LY'=A8:LXEL^PU*/K MN`;KV_*J',?/$A7W,54+HO"UR_#1](KMM0JMG>5K8-I"'R`%"U?>1$W.TY/7 M*<J.I;X00/38BLXR'J!W/9L267>2N_/YV*$$G&XPGXTLS1VK=SQM)L5!A*&? M29F9"/.6+U,UPD39$SK%JI.74`.YR60+!>`P@RBE!X^S$2H8RUW-G,YQD[W0 MH6R"+(a)PW)T8G;_/4I-75.R$8A"$I1G303WZTCR20S`:7VP05%I,[?CBYX-$K M8XOLY?"DA=W/S1V_A,K'=%`CTF0`.GAD'`_F&(_,1M]MJ/.>@\J2W#NG3NT^ MY8:N;7?7RYMA/;^;;$Z=K-J=ZN/NE"H.93?J^7"3#:83?X=),N:#M'86%>]S ME?R]P$W`;:S<3*L3N-E--+.%M@'PC07@'9+U6(CE!#`'L[Q9=/8S(WH@Q_(1 MIOH&,[P%!3]HZV)K[<[CQ;05IC?"\]GQO\^!T@F#S,5T1#>%+Y*FM*6ZD\D3 M@@$._G;\IEH.)E++BY-`"@LW($<^QKW!5&&PB`0.\.GM93H+@903*U5-TN13 MC6@^7-A!_O9;]?*U+CCN#Y7R"K+=\)(+?FT+!D&:5_"`"WYE"_9ZN2WN<\$7 M3HNCW()U+GCPVAU,/:=@[245?&X*ILEM;HNU`RJX;[N.\D==VZ>"==LUZE=Y M!9D_R`(1.O@,LR=OHUC6>/[J:+(XP.6A-:A>-$M%(^&5(I$),9L)GV$<V!5# MD>H^Y\E7)3PQZTERC$'2QR(a)XH7E.$-(FRZ<IRX<7&]FX0M1$`?3T9Y@J&\/# MS)/X^=>EO#+(:6V9KW++X/ZQ+?,BM\SLSNWK(*\,:>JVS/.\,HG?U_Y&?!V% MNF@:6S*+=>*MV;9U'L;V#STE:!W?7TK86@0P46]/S89(?95L)?]'H466VH(B MF2\<?E%R>T%:W8*J-Q()F\TR]YLOR=.J`+\\*G7CV60W04../B_.YV42T_4@ M?G04)3E:%K*2NZO(>RZ78$,8IPO:%/K:+L_CLMK/LOBRT>A8E^_GD-."VP3Q ML79KT"@/JR(#?8);$^MHHI]1!/I!@[*Q%Z0?>;..'))LAV7#YU;KF-J".+OZ M,2?9D^/A=(a)=A`B6S8.AS+C;MHP/-)B9-H8C"J;2!#TFR]@1JB'&:Q$30#4X! M9>+C=0(:.>7/(WHQ6U9CS3@>@->U',,@(<=($L]G<OW<$OIWJ#Q#Y%O[#Y9Z M#3`D?E,JSG?];6:0=-J/<P)@PX#@_B@,$@7XLM&Y'`SKG)DYCV_5"#7P4*YN M^1AQHAJ];<#1U29DV.C1F0QJ.G\9)@(+9Z'93C!@H"F.H)CX4$/RWO`XDY/> MZ+9!RA38EKOS+VY$6Q075<;GR+'CD7_]C<>EW7-#>K5J!R4VO1C3Z7:!??R$ M2<VC67[K[N:YW_@")]":)$P,@WT#W\;S_@UR%9U?>*&5!;]L??5>^!*?JG&9 M;N)>+6S'E2Q#XDAUL^.T/&*VX'EJ+;?B5P962PP.O[<9R]FP<<_#<%@TR6J, MD`_Z'P'=HW!P;:/&/(;OQ;1E7-,N%+9)W.7SFKT/<U)7N9"N#D9;C._<<(X, M>+D^;?O>#:7Q:&L1#;1;DA="83!@(S5REZ0IYT[7BMFRL"V=K0VD<]Y8\Z:J M;&.IW4GRL^'A6]E;Y?.=*1_/I:W@!<RY&,_B"C=KEF@8643O>&<=K*?"Y\4R M?Y@Z@H[DN5N#C\.6+?YDTP]1@,ZKJ:C!BPQPR0A9@_1T*#]M*DX0G]T/$H`Q MD1OH[(D0>Z)#EL4&\/MKJ2!8(]`<WCK6YSS7K[/LUM`#/(CK%*S.2G\BP!P- MS66'6WL/EZA+GF-DN1NQK#Q-:=&JS-M&7=2NP*CL\E;%9]75!NDFFZZ2:Y(+ MNTX6]ADB&%51QG0/7!;=&/S:[,Q^O:&_,]W8WTE=+:B&*[T8G;93[1%H[\J] M49)C)EECIU5YC0XN/EF4XC415.5#Y5T<F[MV.L%D0"?JR0#@7;///O!+S(N( M$1,(a)1[391P?HIR&R;?J*;`58#Q.?OC+\Y'V7%/#SUE7WW46C?;1C[XX@'MF+ M@V2@S)VRT#RQ=!@7S)8,6>]3\4V@$I[(;8233U$23\:4G_+V)@)E;4P7R_9" MOE^X?Q--^:(QF'AHN4II7_@F7[F905\UP==VT^5#J)0/XOX>PGX,HJG;U%91 MZMR(**CHTAB*/KT(`N0J\X+>%M&77.(.4%G5RHH4.?6LQ+=Z#KF1$<:V+:]3 M<[LB2J-3G0`.PH]Y6VCC%(<NK,#=A#3XO^*+6-E2-2GR1W'?Y$2G$%1H15+^ MX_7LR>B>4A!1%%/B92#"<-:`8I_2^922T^IT&9011#=F\_,3\L'H&<7Q1RW: M@XGZIM'\_ENZ/<GB>DX14\4Z.L5=GS@.FC-.8-.$G7I97_Y9>@IC+O,FFX<F MR5%AL%16<WS%QT'I&V7UY@(ZS7Y9IYQ8?IMH@6O<84/_>>#>;,2W%6G%B@O0 MW2I\$25N&QR4;`RK+E+WBM2_RBFR[Q5YF5/B.98P.X\2([O\YJ):SK4BC*3` MN;GHJ0Q25>CQWS/7BNC;1PHM+XG_EA<:Z;G:XFH131AUK?)]]L4BF^&'DIDQ M>A9O"&GM-PT^+!&HO](+08DZW*GD("KC<5MWFT@64QO=(5)?T*!JV96B$T'] M6DO%NUZ+L/+CU8_=T^-SM:OV_V[+/2.MQ+D##%W>;N77.W(4>T2I!.R%K:!@ M7V,.X"C0N9%H=OEJL#>UURKZ)J!KP79W(SHU_VRZN^LNJ6($XWI9<A>6TY%U M++HMYC7XS`"Z,7%E%Y]W>9A_=YA':HN+SI/(Q\>7[8NS[F7C_7'W;^W6U7'W MZ/BT\5/WK&,Y[>IR@)&Z<&*SS;,-J1)9/1:MSLVE&:"5>;S=WM;`O_'N=:9( M^@FXTY<T%JQ>HP6L/.3V;$MTP7J=[G\0T6)!PKP^P-:-O#$:$P+F+:4<R/17 MU"%%:B^#29I:!.HIY9*Q`L]FTFE>G)^TWG>_`Q4,-3(D67@S5)5Y<JXJ=ZH_ MG5-?U;ZJ_(AA@C-^?0?\<=";7W>_JCT/X>6\T@,ELU*K'E1K>U!I;SSMO]P_ MN-MC92#=`Z#P[WZUXY6MCI-/:\KO5"J5;=HO[-=J^Y7:0:565_NUPX.O#_=? M5&OZHW9KSVNUG5U8>UO"4:B_^KH&C6*[M?W#6@W^>.U"OSMOWZI*O?SB`'Z6 M:^KMVXVU?6,^]N/I?4*ZZEMU%H-U$8\"F+M7KUYM93ON\>*>]$>P<M4WG,&^ M>O.M7?'^S+N%IU,@H'1<!35I]*W[`A[NC<=S:N8!)]0S5G36)#2HB";3.=[# MESP'=8)W[]$1SN:5LY\&)5#A@*I1RIG"AG1M]60Q6W\Z#6PD-EZF1SU0!Z8Z M"GW)^?39'T`_0U:=A7<S\P-4]NN)VC>_K^FZA1P,9)\<LN&(T8MWJ-N\*-.? MG8K%`3S6SY_#<_(a)C.1A&M[WDKI`\+R<'7(7SFIM72EX]-X_3^TD?.U3RN]<? M);"6RACL_;#<!'GSOV!"9PE@[?QO/_VFY@O,U!;>2O.2E7*F[YQZ$`UD*&&1 M'')IPB.,'-0L/"+2T!,WXPE]44:D@`#(F5/O0S.K<&YKO"FOA8/Z'81#IN@Z MGESM;R4:JOV-./BVD@&:A6K/*[67E?V7JKY_^/S5X8OG"P('!0.*A-UZ>?]E M'27#+AC<NT")Q69)-0W3Q[;H\?M1V%/GH/M,XT_JF^L)?WL+T%3[\?A;*M/! M^X`Q4(5S;08?01<D[_((C)8[;8B36C#!RR4#>!),WM[`"HI'`YBWN#K_B"U1 M:]\%R>`VD$1%4A>UU[/+9KWVM;ILME0OB0;78557V=O9=47,>`Q6$LB&77B, M3@%S)`(?Y$L=IS[B4BI#2?3OR/4\BK3.[_YC[Z#DOD55DMW5UOGYK,0:ZH>S M=UW<G0+-N';W'%72;-4&O'RJFP#ES'MY`B^=MW7_;;/IO=W/O.UX;Y]GWOHM M'_S=!8L1W87VNV=@ZM#UL/EO6_"Z=G>PY"VH]_!V?\G;JQ^QY7K^6SQ"C7&& M+W/?MKGEV@%,_B-_%OOK`*S-DV58P+>-1F<)%O#MNW=J"1:H[NDR+,#;3OMO M2L:95[=%4-7V<]^V!8/U+*VVCQM'2M7]AV0_@5C=17:PN()E<>R!XE4!K6PO MBJLWM.RBR0B;<)SPW5'X?+_X";3%&=Z#99<$7?.[L_M/G#/S%"R3U_@`_W91 MV>MVX7]=N]LM/F'5X`O@6>4OZJ_![MK9+8@H44]FMY&"Y_`R^R9".?-$':HG M;Y(GF'1N5E*';@%\2B"5U9,Q?&?X2@2-V$L,W"]Y1&)&3C84Z&\KAUW6FQ-Z M_/E#%:GY11W'NO]:A5$8Q3P&"^'B*+#=LC,@',,O[JP3XQT5R?CB-@S`#!U# MIHNC23GBILQ\RN3M[.)X8?!B^BWWLO,X]^1>3^3D$OXZ8A<'O&2PT'',;@6. M`I1:&.E'UUCY9:4O<PJ#2[/!N9`KS:TG@#DG(K@J[W:::_1$=5L"8,<!D`*G M5H[+9Z-VB`5-\-93P/,ENVK=+M,6T`?(a)E)&-.\\'N//`D15Z&=')W:67W^T2 M-'(='4XJ706*HU!/,RRJQ)P4G21Y5]1]:ZZHTQQ78*_4I1LSED)AL]'P#HWD MBI3A/-]7_31YO<G0&(.#F.'YIP8+JF.DNC]:`5$/\$]%+/4TPTI1,A?$SQHZ M-980@=O@8G.-4VSMGT;=T/I'0<E&BG8T`2(.%11G?]*N>*MV"SZ""[^L'T&3 M1[!IGW.PPR=1>A,.MNN:EYI<J,I2X^G3'!10VH%M`#J/%=1I?K\Y.`[)%?C9 M+YK:UUVSN+L`5"Y,6)>X>P8H'Z:UU(XHX[-5Q?E+O'"PK/#_2.0"WV[+2R"? M=ZB?%_2JG[.ZU,^$JR(V]M>,JG18*[D,UNVG"-#H9(D,$2N'NASESC0KULPY M8K,FO,#A8@YFUB$&?CO^^Y?J&;I7C6/^>G:C,2).]=W"@]#CCI]:<MSA,!;) M2ZZBW=U2AJ/H+A&^_XS^[B)(D]U:-!5ZP)`^OA8B]?`4;80G\1IO@";FBUO@ MB<FF:/.[`RG\=4$5/U2+-(2!3^CDYRU:EGT.X[5$M#&N%]&(RNH"%G5Q`,"F MC015`0.`,"D09S2*_0Q!;A<X3!EP1>UCT]LAK)!!3Q8S6>!(!]+0K06HOBE` MV:X-.0JM^H)0*SU+*=`P+$-MS*IR-]36D2*'7:$@AY(83P7M/2L]Q78,E;K3 MS<J-RU>N8YA"/*:9944..R4`S7+#70@.$%S>@L=WG@;N#C'^5\+-(?KR&4`@ ML>+VQDH8`!7NFF8D"@)E#K'XX2::I#>/?W+)J+0PJ9;5_FJS^C]U3LV42!/9 M.7G\*5D6#8.HMM$P4!:C878?&@VS^PC1,+L;1,/L4C3,;C8:9G?;:!A&TY;[ MIH0Z;]\4T;?1%NFN!=%ND3(0G[]%RE.YV6ZHF.N_F\.[&]XA"51OMO(XFUI; MN;]-+717UROU.KFK7QT>O#I\\?6#O>"V]<UW2>NUYW:;%,P"[3'N'O]X>=&^ MZGX'3QU7F7WZ@`QVM/=CO>UG,;H0@NVW5_V/)(S!]9_:>Z\8]H%F2K3#E)J4 MX!+AX69^U%MB<C7,Y-YD@)+MJ0@(%1@/MA)$HWD2`L\YX6\4'9WJ&V("VO4: M\D%&2<!&L8UX@SEEF>)[XO6%4#"`V?TTQ`D()_.Q(J[,SAF*.7#C-DC3`<%0 MEL=T+0'\^(4+Z4B>%0B9!>E'1L0B$GCL9S08BO(a)_;?QPC.%4Q`3Y%^62-T%: M.-3E@W":[B**[`DR&ZD%HZ'AN(^ICS<4L,8#NVHWSCN-YE7KXIRNX:`A+O9G M<FUD>FN=7W6/6IW&N]-CKSM\?GPNCVUO\!CP^N'R:E5?*65UUSU(D)W7NCRP M[>*#54W*'1]>JSHBS6W8/K-MRS/;?.XJ58TIB,K&92MWI9D@9Y"3HTB$+!:. MF!SPACJ0ZY_"D5N":NE,>S?VHJ.`-GW-G9F]^VS0,W2E;RMY0F>!HOX3*D/3 M.`SZ(1TA2V_B^6A`'L<@FNB#D73NQ(0H2WRUY!F,QM-1B.''@27JB\F(3P)( M3P9,WKYC#LI@4G;`J)<$R7WVULW6+"444C#T%"I'/=[;1I7B-ICR2I,\=.*N M1M.GJEH32FT#V*2;-5C?,#&/-\!7/GEW;\JA6<R-./DLQKBGSWFKY6FN9FY` MNYPM-;F</,\RO\O-:J54/.7Y-K?%X4V'#@F!7H2W4Z.KR:#=(%;8U#1(@G$( ME?'2Z'O#6S10DDR'O>-H7LKSZ#J:0<?#:(3]VNQ&:0`T0'?O!<ZELDQQ)B,- M9?`S5WKIB':#(F'GF,M*LSBPL4-[EZZ;:(OQ6]QQTEN06L3:C_-QTV5A5SF7 MG2SR($D)5-8MK,B1I=9\EF?/VJBV$U&!TUE\!A/=I:GM:KR61+DM5ZO54NFU M<JX1!,(PQ/*$?8]/LE$1&WR>>6S%YT5;MZ7UATL)>20F@<N.D..(L+**D8FX M,@K%HA5E1&.X:@T#PM2XZAUP*WI,U:,)W4%"-U;J^[2HHF1]DIV5U$[+GEN> M^^B;D[4H1<@0LG!R$30KI0R.(W._%5/=@!+R47F,9)7B]MI&+V^LR>;&%>QM MBN[Y-FF>+\FE$E0XY8L-O7!TOLC*O=4Q0+XRR!N-?&Q`[6;50/D#"]*Y!A`/ ME?!#TNG*.D,MS@M?Q<KU^#2<+X+MI8)X1M(-3J?`J+N(\RBO`'VAH6#C9I;R M'E^!*^;H+YIW;+HV\O0MI+B-&_`9H#$!/Z\Z4M)V]<6+LW%Y]][3K9!DU#DB M[ZW@(QK<JC-7O^/-$QOG_>O&A6UG'V]I&+-%O%^!/_6ZJG]]6'MY>'#P\+BP M;4SAY[57^:9PQ@;^%S5^-8BX_2?AF<62\B*Q*++0#[]22C*:88"6]_8D\_;` M>]NDE_;M2^]M)_.VZ;T]\M_6:[EF4,;RS1B^%%`FUJ^D0)!?VA3&[SH;K?.3 M,E3+;Y3=;G&0W7YMNDU/]X+WW,EWN=Q36UV.O>T-`WF>R'$>!T64V=3<+VD$ M%$AF'Q[P0]QOL0_W^2&&C=F'=7I(6U3V8>TE/FS[U6L'QD!L7IQ?M2].\X%U M<:XH\(L,3@]<12%?[O,#>8[!7N[S?5W^U'_.<"L*\'*?$Y2*3M[[S_?I.05U M><]=D[IQ]:'C#2J=)7/0C\BB[E/.L7_N9)+.X4G6Y%,XP.OP]@]>9U]3`CGZ M'/(9%_]MI%_GOD758?E;3!>W]"VE'UGZ-EG9LAY2'8?TVDSZ5?MT*7)2.CB_ MB!Q*($G=Y.&&LD8N&QYEBESVDK)#+JTY6C5RS`*YY"5G?EPZ5RN@332Z^:4E MJ"7N&>M3<MU6"[ZJ?PT/3#1;[8'Y'^W8V'OFP&Y&`I!0A@]S0M^X>,J,H1LQ M]1.5WF#):2#9.?B`SAP]#`NG%L;A.$[NV>0A[T,O2,%P0-GZKM'FT_O:A.R@ M':(-']>`TM=03K#EI/^)-%IV3+6&]KYWG.844^,$=#,YUKJ]B3$IM#6EJ,@D M)WV.F$1FNNET/1W*5R8-BMT*TU=-8E8"K"U7/8^CP6`4"F39.Y[UJ4!CG^#M M+^C%AD&(7\X#!2IK(`>*@=&6FMA=/"^NB>WTAOZ7Z_R;J37%!Q.ZL,%QHEA[ M>F6.0>W0R4V!-IW/BGZ:\LQ%Z1B*ZILI>D[)0V/3SK@YT9V3/]F/WY;8(MWI M#)ISG"<./?7H9A^;W*F0:8=@9CM>G$^81`O&P,WHNX!DTH5>5S9F:+2LC`?* M-<+I#@SK$P@Q<9/7W*H/^Z0RU+.BQ4*F70-Y(0NV7(%<>JTLV)M<JKT>YN7C MR+F$N[QP8;<=A.$>;4FUL\!`*";=O8@=_3%`((%DX,SG(7(K2>C@<#C'^]$F M`\,6N"%[%8\SH\L8S`:\P23]1\:0F5;-PPQC^-=8\F`\;;ODG4DH<_0V_LXN M^)SUM&Z1VSL3,@LSAV'D+G3KP+-7V><T]QCK'"GJ49>YTZ"WS/\7+/$_`S'6 M$$*]`\U!$K@>\1<G`_1VI3@9VTSGGUNG8>#N1Y20IYB6T]8*AE$NJ.*F"H;M M]S%4#5[7RS2-+9:ZH]T.^'2ILT7(5Y&5I3=[E9VKJ;*2F&&+<K,9LJ"0?<%X M8YE3RTF=::\QBY`\@CGE2<*Q8HP8)L>S@/+G1.(3@E[,]UNE6B?RII`O/W-! MQ3GE3-GU;)LP7]=),!X;M5>;"1PK#@:&X(0O!91:.F^[N4`=3R1H>B/]P=$N M^:,OW(ID5V,9KR6RSW#;16;[>%K1(^M%2SFFXKVN+32C%5SSH2J19CIJ(\5" MA\&MY1N_E5*QP`6L3O$(TAY9;7$[:?\Y\GHCK7Q#86WG]4'4]YO*:QO;AVMJ M6./P*Y(a)SNBQW.+1B[ZDC#XT^'`V=@`/9=L/->+M_9KD8)VCF>W:%?ALDXL*@ M?Z.&T1W**[SN5_.R<N;"/MGLYU``K6NR1-=;J')>#DF=TN0%4V"MTR1":C;M M"!-E2(1S4S6"<"557N%(NL=8;@EW="H4G\E@2YFR)55:[GUZIKX/DTDX6NJ` M,DXH6XY5$:N86!^25@52$:Y4\:+:^>R4AN+>R0=>=JM5:^_"HCN_LG*.2'A& MA.;LVI`R._!JT:+9AM'H%:.W(13%:&/B1(HD$>*5H)EL#=ENP!JH%P`E8F$@ M1A#;&$*PBF8ZJ'JNMUQ6W-^&RS.S>V\TN!4N"V5\G?0#$:G#7*!!=(H6ZR7@ M'M/Y3,[/E0R;6,5QVLT?BK62@IIX[P6=X"SEZM,Y0Z,8<V,-;&$*>,UOIN&O MYYXYH]/D^3Y?L\95%**XPU?$VYS0S%4T$$_S&89A!4H=X2T(\22LD(ZC%531 M>QV5,>=:UVRJ>'.@1PC9W/V\N%!6D:Z31OSSH!<R70H\;@#^NK"W^Y^V!-VW M-WY5O*]D&R8K^#KX\\#_'1%O4H$O@=L"ONX2F@QGE[UD%VQOL*YCAQIA89<= MA>3_G8\P`[";UUW?4KQ2`[!IP-=,2XYT7+A<%=A@CH04/\+G7GVZ+#Y4W>[% MB^&A#H5L&WG)M3+AETNO.=U``B[>>&K%U9)[3Y>P\:4!GMO<A*I\.9AW*:KK MT%IQ(>IZL;/VOE2_'2.FO-ZRM]2L642L]3B+IQA&Y+<5YAV+$E+*69KYBXF7 MD;V10:^HE;31:><F9W?X!%XZVEJX<M*]2*_3=CM82/^^0E=WKGLR_:V_Y#(S MG,5[*]?Q[&4W!>:,K;E\;)C>?]78Z,X?UK/R+_K+##</%'NM6W;0"Y>UK1NT MSV#$<\"RYS9./BX[\<+G!JE$Q!ZU=#I"XIV03>.VB0<HS3+,'A^"EWPZ4<MV ML^7LY486+Z0-_!:C!EDO!J>"NCR39.I>1=XVF4AU[DE[JZP[YM<*)M8QG'\$ M%/]O"BAV68P74,QX?F`L\4/"B#\_@GB+X-]<_]ZF(]L^]G>KL-_?+^+W+/@8 M#BF9UZ;AMKK&YG&_ND;.8=BO'A;Z:UK>//KWI9,N^,^/]H&VX(_,IA?U*SF% M6Y-^%8-_O[;%&F`UM5OOO[OJ*)C[X_8/QT=>,S_%<W+%X=93[UY[AVC-Z_9' MP'TG:2C!8&6Y`:>,/DO;#FB"LR3JS<7)T+DXN?I;HPV4'"O*/X67#"$_P=N< M>!,2)11I<W@"+W2:TF(KP.-7S',PT?ODGGN.$+S)8(\XO>UVH'#")#!+-\4[ M",!Z4[S=S537)6GDE+<,6>L`8>/F4ZI0M0V=QQH-7$GC"5"&YW(D9JZL0ERY MTW"$<B@V=AQE$'"ANE?3`#,2IU@.F.@@'`?)1Q),_FQZ<W7E(I8O,>%-TQC1 MHYXT.JK5>8*Q9!%[E#4F;X,$X;UW!G05BU?R+AK/QPK/@4PH0SOM6+I'H%`W M&06W975V<771OCAMJ*-6IWG::&$6>9?,`"Q@S5>MXX[ZVW?'5]\=M]7QCY>D MNU^T5>OL\K1U?`3#.F^>?CAJG;_7CVPK3(a)L7)^KLN-W\#GXVWK5.6U<_82,G MK:MS;.\$OC?4)7"R5O/#::-MF[C\T+Z\Z!RKQOD1_/U)-_F3:KQOM,X[H/.> MG[2A\^.SX_,K];?6U7>V;OOX?:-]I*XN%`!O,5VT$&.+P#I;)P"V^N&XW0$A MY&`!QWQ\<5(RO3>:S8NS2_B&E3$+Q]7QN3IK@/1K-4X[F=G=?D9:Y^K\0E'T MN.I\!W-(a)6S.3]>Y8G;;H-#(A#8`Z:IPUWM,D-:XZ&'ONH,\9*^(&<[6>MLY: M8"S`2,NF*C:%$>PP3;;NNP^=%LW.9?L")JI3MD^,P*=6I*9Y;9N`R;EHGTEG MT,<%4='E<?/#>:O1_HEJ`G;;K0Y""$W@1'V`Z;YHNXUHBH&9Q)?N;`K.'_&S M4P&)^OX8XW5'40_/B004F$$W`F&(>>5ZIR(_\-=1BQ.E54Z!&A4_^P[=\ZH" MF+@`')WAPYU*LZGD_5X2I?V]60Q*]][TXW6Z-P:FB8E]]WK19.^F/YWVH?C) M:>-]AYN;Q,2^506D]W?I((5_X\D;,.&2[B`<!F#\=HVF8E]%:3<)IZK2JE;W MH(a)E4;2WO.,+<T\UFW/L'0?B78K-9PG\)"/Q&(\8O-*+23@4XP:7*+5RY)(2I M1IJ&XQZ&TI*#`S??Y]&(L[144SR/"]RWJ-,M$52PLI+V$*C`WTQ0GO1=3>- M8/SXE)$/3T>J,ASCD\T0&Z2$6`3M-)I\Y."+'L7"5&,!9Q9?A^2"(#L*N'!X M%_;G,URC5:QZ^CW`5'BC5.4=QOB^J:G*?ZG*OT]4)<&7S;,CGNS3UOGW#-,: MH$8#``J01W5+]`5Z*#&81Q<=]8%BC*,PQ4='QZ<RU`0&WKRX_(E_]:?8)1,@ MT"V5O7CW;\=-T!/>H')<AQ'2+0DQO@I&HT/HB@F=^H*)#_NS%)]*/7ILRO@O M"@`F#+#D/%256/WE+=9!`8R7$!>0:$[AQ5`]@]Z?52/X.PZF\.\(+%/3=*;+ M:EJ-_=I_@:KT`$FNA*LK'<,:47_YAIXVB#Z)6$I2]L\+CXM"-EQ"?8O_`134 M85]W2/1?HG;I<>H_+L(*UV\9I8?*RQ'#)^'H55\*[4LA?KY?37\#M;P[W2)- MNU-I>^4<*OUZ^CDVOKF*_JK^JZOH8P>_<M""W>&7337^F-(]P^A'`>5Y\O'Y MOCNH/U3]/U3]/U3]/U3]/U3]_V.J_OAP+QX-NJS]\;^DW_^AZ3],TU^)U]]' MT5$TA]J_O]6-3_;X!*U_T$C_?5L!LS,>W:\N7+.Y3>W%+C\XQL)TNXVN2Q? M6`,!\QR`Y#V4Z[8D)0E_HTGEKS1O.Q64M@K5"9!&()/PVO$.5>6L9,Q/)/4< M9J$&8&NJR`<F2KA-LU.16%A]%7B5[[3U'^K3/#L5W'S'"Z$XD^R]36$73TFM MQJQV]^DL'%<)AGL*NPAYPW$Z3Z9Q2CNT_7@0<I*S4%3^?\S'TPI?T,$&C-Y& MUE#KZ!IB@?J@"1\QX1:3!/C'1#9=FZ#+3*[GP76X4TGO8?QW=`[%X(1T]'@\ MI:R6H`2=B0R""=#/$])V`RT_J-_C\Z-6`_4CUETTJL&JN(X!,S=CU*#Y<([$ MS8#0J,A5L11D"N#$PQE=E14YI]5'(9>F*+5;4,GXJ,!.Y4,'="/JI\Y3<Q,# MZV(<LQ6"S<PG')1N)IGHA,_+C$#.R+8[CGR$MZ4,R#3C!LT)<>6E)LZ2`#>& MMPR17*+R0;\?SR<SWN4&4+)U)B&+7("/"7>"F8LQ$"?%8T9(!'+R@L[Y4\`; M$:5RDO41&O87!Y^#/GT0GL]R*8]^^#HDQ-*Q/B-O!!M,O\'!.SPE7U4-&*P3 M*F[CQ_FT6"@!XTK?^(@X6-HP-\K-@\16#8D.:,O=->8\?IE-6@F1H`HFLR#A MX7E5O<M$FZ%Y)V-T4OZ5!8F+87)`[1BW)F>Y*/Z,RIJ4BK24$+&$+9O9L"H\ M"0^EV=-SDG+'7,/#=-+C&XQF(4]\C(?.!C0Q<B1+X)+;L5LZXLJM9`_:I3,3 MS0!PE-&^Y1.`%(=T=7&))B_5`:EU#"P18X[:4'`03N5H4#RQ@1C2":,H8%<" M)B"9\1D+2>`83HBX89T,:.0'53F383!Y`Y/5"T,DZC[2+AXFN7=P+I.@#ZPU MW)R2E`0#CS'H<!*"3$:A8\3HV7P:+T;]@^&L`]&H!H5>$I@O")NSQ<42C-+8 MX:O'ERT>ADR0)B(YK\?5D*#,S&J*E\@T2S#4E%U?Y**@DAIB0&X\3P!%FH1R M(#3GK38!,7/>Q#L'0X5M<";R!3I%HX'QSM$8@&#A8)[#/BS/M)R'OF$2DK=* M_"-,H>AKN9WD'>(AQK80?<BS:R(0=RI?,5]S.(UAGB*V,2H&2)-1,)2\'A$" MB:%_V,M[/-F&PW0@9O87J_^B^#4LQ0XVCY"P5SV[/#5?`_&8<"JGN2\7$JO$ M0^H"VI^'>KZP/3S>0N&HZ<RR;)9&C$KF#][1)*(F"9KLQX);"7BC!OD,$A&V M7SS5!&FCSKF:R:"%?&4,YH`I:9<NROE1R(Y)!VP&=A8XZ70;?CH;0M7+W'6& M[5+*;."/$XKQY(!1:I0$G@'!Z1+8R'QF#AS?!I.9GK^>)M50>P9[A&Z)+Q.W M(B[^LI%X+CRX@#7_D=#5L<9P9E2\GNV!/.*'L4+)J07=/_0RHZ)R5L4M3*=W MV:?(07[8+ITV@P(I+S';`RE^RAR!Q\[*.D\Y#5(./_51%)G\J$;`V.0LB#US MM)-CWQ@;3H0CJ0O`!_``WB`F3F,/<S(/Q>`YTU=57<A)Z0PG$-F$\9GN*7*W M+RT8!&]"9LQ6Z**;+.H11<[@Z`IB![N(61\S(B:F(8T_@Z8<%-EYH9,,>?W; MOF4%R#1I4JP3V;\R#&L)`V:N%:8B7"GEDT[>;N-;^?@I<AON+-=*8%8KW(7* MN3,1X,EUG3=*<V+BP5Q4^#!PT!F&Z4HDIN8?VLW-95$9AM$]KC&[62S:9O%G M;LS9\PK^^8K,2OCS<GMS-=.:OGUX_T76^-6W#^^_*-</U"[_!V:JVE&GK7<% M<D[^I=B\_%"J!O"P0H0(C\F0JW94)J\E.G]V,V5VU,6[?^O`;UA`T[0:(][Y M7\:^<RX#W])EDO#__W/#$'4WX33JTS_H;,KTC8^F_:@:>],7N[?1;M+,DE8` M(>C2*E19XU1_*=(PR6?3>E?"]_SML$#.)O%A-=HEU4\^J;^\5?(X%V6Y);%- @CQ(/=U1A-%&55%6K/-5?U?9\6O5^[?Q_<NX+P)0)`0`` ` end -- Gleb.

1 0

[U-Boot-Users] i2c for mpc107 bridge
by gleb＠nbase.co.il 28 Aug '03

28 Aug '03

Hello, I tried to use I2C driver from cpu/mpc824x/drivers/i2c/ before relocation to ram (to read SDRAM eeprom actually). This doesn't work for me. I think this is because Motorola driver uses static variables and this can't work from flash. I wrote my own simple driver (attached) that does work from flash. May be somebody needs it :) -- Gleb.

2 1

[U-Boot-Users] Auto-detected parameters CpuFreq and granularity no longer autodetected.
by Seb James 28 Aug '03

28 Aug '03

Hi, Encapsulation of following email: Does u-boot pass anything to the linux environment regarding CpuFreq, and granularity, both of which are symbols recognized by rtai? I'm having real trouble here. I used to be the happy runner of a small rtai driver on a tqm823 target. Two modules that used to run perfectly now pretend to have been insmodded into the kernel, but don't work. What have I done? Well, I re-loaded the bootloader, u-boot, onto the targets and I don't think I have changed anything else. The only piece of evidence is the message towards the end of the console output, regarding the missing CpuFreq and granularity symbols. However, the kernel is the same one that I've been using successfully for some time, so are these pieces of information that are passed from the u-boot environment to the linux environment? Here is the console output from the previously working kernel and ramdisk, which contains 4 rtai modules and a module called ptms_drv.o: => run flash_self ## Booting image at 40040000 ... Image Name: test kernel Created: 2003-07-04 15:35:53 UTC Image Type: PowerPC Linux Kernel Image (uncompressed) Data Size: 1368124 Bytes = 1.3 MB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK OK ## Loading RAMDisk Image at 40400000 ... Image Name: Application ramdisk image Created: 2003-07-07 12:36:03 UTC Image Type: PowerPC Linux RAMDisk Image (uncompressed) Data Size: 3072000 Bytes = 2.9 MB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Loading Ramdisk to 00cc1000, end 00faf000 ... OK Linux version 2.4.4-rthal5 (seb@mst26) (gcc version 2.95.4 20010319 (prerelease/franzo/20011204)) #8 Wed Jun 25 16:28:38 BST 2003 I2C uCode patch installed On node 0 totalpages: 4096 zone(0): 4096 pages. zone(1): 0 pages. zone(2): 0 pages. Kernel command line: root=/dev/ram rw ip=192.168.10.99:192.168.10.1:192.168.10.1:255.255.255.0:vmu::off panic=1 Decrementer Frequency: 3125000 Calibrating delay loop... 49.86 BogoMIPS Memory: 11568k available (1020k kernel code, 428k data, 56k init, 0k highmem) Dentry-cache hash table entries: 2048 (order: 2, 16384 bytes) Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes) Page-cache hash table entries: 4096 (order: 2, 16384 bytes) Inode-cache hash table entries: 1024 (order: 1, 8192 bytes) POSIX conformance testing by UNIFIX Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Starting kswapd v1.8 CPM UART driver version 0.03 ttyS0 on SMC1 at 0x0280, BRG1 pty: 256 Unix98 ptys configured Found 2x16bit 4MByte CFI flash device of type AMD/Fujitsu standard at 40000000 Registered flash device /dev/flasha (minor 0, 4 partitions) Found 2x16bit 4MByte CFI flash device of type AMD/Fujitsu standard at 40400000 Registered flash device /dev/flashb (minor 8, 2 partitions) block: queued sectors max/low 7586kB/2528kB, 64 slots per queue RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx PCMCIA slot B: phys mem e0000000...ec000000 (size 0c000000) No card in slot B: PIPR=ff00ff00 eth0: CPM ENET Version 0.2 on SCC2, 00:d0:93:00:c0:a4 RAMDISK: ext2 filesystem found at block 0 RAMDISK: Loading 3000 blocks [1 disk] into ram disk... done. Freeing initrd memory: 3000k freed CPM load tracking driver $Revision: 1.0 $ NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 1024 bind 1024) NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. EXT2-fs warning: checktime reached, running e2fsck is recommended VFS: Mounted root (ext2 filesystem). Freeing unused kernel memory: 56k init init started: BusyBox v0.60.2 (2003.07.07-11:04+0000) multi-call Warning: /lib/modules/rtai/rtai.o symbol for parameter CpuFreq not found Warning: /lib/modules/rtai/rtai_sched_up.o symbol for parameter granularity not found BusyBox v0.60.2 (2003.07.07-11:04+0000) Built-in shell (msh) Enter 'help' for a list of built-in commands. # lsmod Module Size Used by ptms_drv 24640 0 (unused) rtai_shm 6512 0 (unused) rtai_sched_up 59776 0 (unused) rtai 21232 0 (unused) # If I change the ramdisk for a different one which is similar but contains recompiled rtai modules and a different driver module (driver.o instead of ptms_drv.o) I get the same problem and the same message about the CpuFreq and granularity symbols. If I change the kernel for any of a range of about 3 slightly differently compiled, and previously functional kernels (all from the same 2.4.4-rthal5 kernel tree from Denx CVS with label LABEL_2003_05_01_1320) then I get the same message. RTAI is 24.1.11 from Denx servers, u-boot is v0.4.0. The question is: where do CpuFreq and granularity come from? A search of the u-boot tree for CpuFreq gives nothing. A search in linux threw up no CpuFreq symbol, either, but rtai mentions it in rtai.c and rtai_arch.c. It seems that this is a parameter which linux normally autodetects and one which can be passed on the command line when insmodding rtai modules. The same for granularity, as part of the rtai dynamic memory allocation scheme. Adding allocation for these symbols when insmodding doesn't help: Putting: insmod rtai.o CpuFreq=50000000 into the startup script in the ramdisk leads to the same boot up messages, only they come twice now: init started: BusyBox v0.60.2 (2003.07.07-11:04+0000) multi-call Warning: /lib/modules/rtai/rtai.o symbol for parameter CpuFreq not found /lib/modules/rtai/rtai.o: symbol for parameter CpuFreq not found Can anyone help me to fix this? I'm really stuck... regards, Seb James.

2 1

[U-Boot-Users] mpc8xx hardware i2c
by Robin Gilks 28 Aug '03

28 Aug '03

Greetings Does anyone have stable working hardware (CPM driven) i2c for the mpc8xx please? I'm OK with the bit-banging config but I'd like to see the hardware version work:-) Cheers -- 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

2 3

Re: [U-Boot-Users] Resend: The dreaded embedded environment - linker barf!
by Wolfgang Denk 28 Aug '03

28 Aug '03

Dear Robin, in message <3F4D26AE.5050103(a)tait.co.nz> you wrote: > > My assumptions here are based in part on the names of the #defines This is not a reliable method - if there is no better documentation you have to check how these #define'd variables are _used_, too. > It was only later I re-read the README file where it states that > CFG_MONITOR_START = CFG_FLASH_BASE - makes one of them somewhat > redundant if they are equal anyway. Certainly it appears that the code > assumes they are the same!! This is not exactly correct. The README says about CFG_MONITOR_BASE: "same as CFG_FLASH_BASE when booting from flash." In some cases U-Boot may be stored in ROM, or even in RAM, in which case CFG_MONITOR_BASE and CFG_FLASH_BASE may be different. > I fixed the problem by putting the environment into EEPROM - the FLASH > implementation is broken. If it happens that I have to revisit the FLASH > environment then I'll try and fix it :-)) No, the flash implementation is _NOT_ broken. Your configuration is broken, that's all. The flash implementation is working fine on many, many boards. 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 Far back in the mists of ancient time, in the great and glorious days of the former Galactic Empire, life was wild, rich and largely tax free. - Douglas Adams, _The Hitchhiker's Guide to the Galaxy_

1 0

Re: [U-Boot-Users] Resend: The dreaded embedded environment - linker barf!]
by Robin Gilks 27 Aug '03

27 Aug '03

Wolfgang Denk wrote: > Dear Robin, > > in message <3F4A75FC.7020907(a)tait.co.nz> you wrote: > >>If I change my memory map for 'top' booting I *should* just need to set > > > What do you mean with "should" here? Is this what you think should > happen? Maybe your expectations do not match the reality given by the > current implementation / configuration. My assumptions here are based in part on the names of the #defines > >>It looks as though the CFG_FLASH_BASE define is being used >>inappropriately where CFG_MONITOR_BASE would be a more sensible value >>(for example to see if the environment is embedded should depend on >>where in flash that u-boot image is, not where the flash starts!!) > > > These defines are used all fine, as long as your configuration makes > sense (as demonstrated by the 100+ existing board configurations). It was only later I re-read the README file where it states that CFG_MONITOR_START = CFG_FLASH_BASE - makes one of them somewhat redundant if they are equal anyway. Certainly it appears that the code assumes they are the same!! >>Any ideas appreciated! > > > Try to understand what the image should look like, where the > environment is located, and which #defines are used to configure the > environment to that location. I fixed the problem by putting the environment into EEPROM - the FLASH implementation is broken. If it happens that I have to revisit the FLASH environment then I'll try and fix it :-)) -- 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

1 0

[U-Boot-Users] how to port uboot?
by jiangjie＠nudt.edu.cn 27 Aug '03

27 Aug '03

Hi folks, I am new to Uboot and I'd like to port it to a new board which is ARM& based. How can I start the first step?

3 2

[U-Boot-Users] Board HW ID
by Seb James 27 Aug '03

27 Aug '03

Hello, I've put a re-compiled u-boot on a tqm823 module. This wiped over the serial number and ethernet MAC address on the module. Re-setting the ethaddr is no problem as it is printed on the back of the module. I imagine I can do likewise for the serial number. What about HW ID? Here is part of the u-boot boot-up message: CPU: PPC823EZTnnB2 at 50 MHz: 16 kB I-Cache 8 kB D-Cache Board: ### No HW ID - assuming TQM8xxL I would like to set u-boot/include/configs/TQM823L_myversion.h such that the Hardware ID gets set correctly. Can anyone tell me how? Many thanks Seb James.

2 4

[U-Boot-Users] Resend: The dreaded embedded environment - linker barf!
by Robin Gilks 27 Aug '03

27 Aug '03

Greetings Well what a suprise!! I've been struck by the environment mapping yet again!. If I change my memory map for 'top' booting I *should* just need to set the TEXT_BASE address to threequarters up my 4M flash device (so it starts at 0xfff00000), set the CFG_MONITOR_BASE to the same and leave CFG_FLASH_BASE where it is along with all other address config items. Unfortunately the linker barfs on the embedded environment value which is defined as an offset into the image (well, actually the flash according to the code). Setting it as CFG_ENV_OFFSET or CFG_ENV_ADDR makes no difference (so I can't put it at the start of the flash outside the image either). The error message from the linker is: u-boot.lds:132 invalid assignment to location counter - the line number refering to the line after the closing brace for the whole file which doesn't help much!! It looks as though the CFG_FLASH_BASE define is being used inappropriately where CFG_MONITOR_BASE would be a more sensible value (for example to see if the environment is embedded should depend on where in flash that u-boot image is, not where the flash starts!!) Any ideas appreciated! -- 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

2 1

[U-Boot-Users] Ebony board with 32-bit DDR memory width
by Brian Padalino 26 Aug '03

26 Aug '03

I am trying to do a proof-of-concept here and I am just trying to make sure that I am setting my registers properly, unfortunately I am not 100% certain that the CPU is actually running in the mode I intend it to. I have the original Ebony evaluation board, but , for testing purposes, I need to run the 128meg stick of DDR memory it comes with in 32-bit mode. These are the steps I have done in trying to do this. 1. ./u-boot/boards/ebony/ebony.c a. Line 182: 0x00084001 instead of 0x000a4001 (mem_b0cr) b. Line 193: 0x84800000 instead of 0x86000000 (mem_cfg0) c. Line 202: return ( 64 * 1024 * 1024 ) instead of ( 128 * 1024 * 1024 ) 2. ./u-boot/include/config.h a. Make sure to undefine CONFIG_SPD_EEPROM so fixed_sdram() is used. U-Boot says there is only 64-meg which I believe should be right, but I don't know if that is simply because I am forcing it to say 64-meg or what. I tried to replace it and say there was still 128-meg and that led to a horrible fault. When I boot into my Linux kernel, it also reports 64-meg of memory - but I don't know if it is just getting that from u-boot or if it is going out and finding it itself. If anyone has any sugguestions or reassurances that this may be proper/improper, correct/incorrect then it would be very helpful. Thanks, Brian Padalino

1 0

[U-Boot-Users] The dreaded embedded environment - linker barf!
by Robin Gilks 25 Aug '03

25 Aug '03

Greetings Well what a suprise!! I've been struck by the environment mapping yet again!. If I change my memory map for 'top' booting I *should* just need to set the TEXT_BASE address to threequarters up my 4M flash device (so it starts at 0xfff00000), set the CFG_MONITOR_BASE to the same and leave CFG_FLASH_BASE where it is along with all other address config items. Unfortunately the linker barfs on the embedded environment value which is defined as an offset into the image (well, actually the flash according to the code). Setting it as CFG_ENV_OFFSET or CFG_ENV_ADDR makes no difference (so I can't put it at the start of the flash outside the image either). The error message from the linker is: u-boot.lds:132 invalid assignment to location counter - the line number refering to the line after the closing brace for the whole file which doesn't help much!! Any ideas appreciated! -- 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

1 0

[U-Boot-Users] 8xx boot - low or high
by Robin Gilks 25 Aug '03

25 Aug '03

Greetings Subject is a mpc86x based project. Up until now I've been using an eval board which boots low (from 0x100) but to save parts on the target hardware I'd like to boot high from 0xfff00100 so I don't have to set IIP (default vectors) or ISB (default IMMR) in the hardware configuration word. Can someone suggest an already implemented port of u-boot that starts from the high vector so I can get an idea of how to structure the linker control file so that start.o is *NOT* at the beginning but someplace up the image. OR Can I start execution with IMMR at 0x000000000 (by not setting ISB in the config word) and still run code from 0x100 (so I only have to pull up IIP at reset). -- 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

1 0

[U-Boot-Users] Motorola PQ2FADS board
by Scott McNutt 24 Aug '03

24 Aug '03

I'll be moving from a MPC8266ADS-PCI board to a Motorola PQ2FADS-ZU board soon. Has anyone used u-boot with the PQ2? Any issues, problems, solutions you can share would be much appreciated. Regards, --Scott

2 1

[U-Boot-Users] Anonymous CVS
by Timothy Meese 22 Aug '03

22 Aug '03

Hello, I'm a relative newcomer to u-boot, but it's nice to see a multiplatform boot firmware solution. I have a couple of questions to start with: I've tried fetching the source from anonymous CVS on sf.net and I always get to the point where it's fetching u-boot/tools/updater/utils.c, and the checkout hangs. Has anyone else experienced this issue? I'm interested in using u-boot for an Alchemy Au1100-based board. As I understand it, the Au1100 is based on an enhanced MIPS 3k core. Aside from toolchain issues, has anyone ported u-boot to a 3k core? I understand the major difference between the 4k and 3k is the pipeline depth, which would seem to be a tools issue. Thanks, Tim -- Tim Meese // Software Engineer // MBARI // mailto:timm@mbari.org // 7700 Sandholdt Road // (831) 775-2039 // Moss Landing, CA 95039 USA // (831) 775-1646 fax // http://www.mbari.org

2 1

RE: [U-Boot-Users] Device chaining, anyone interested?
by Woodruff, Richard 21 Aug '03

21 Aug '03

I looked at the POST code and it seemed "so" PPC centric that I was thinking it would be faster to make a parallel type directory. I had written a bunch of tests for another compiler/loader and am starting to port them over. Actually, I was considering using the new "standalone" code model as a way to call the tests. This way they could be more decoupled from the actually u-boot code itself. The device chaining seems to be working for us, it pretty much implements a list of devices which are called in order with heads being stdin/out/error. The person who did the work this week did seem to indicate that the deregister stuff that was there wasn't done very well. Regards, Richard W. -----Original Message----- From: Detlev Zundel [mailto:dzu@denx.de] Sent: Thursday, August 21, 2003 10:02 AM To: Woodruff, Richard Cc: u-boot-users(a)lists.sourceforge.net Subject: Re: [U-Boot-Users] Device chaining, anyone interested? Hello Richard, > We are in the process of putting together some POST/diagnostic type > code for our OMAP u-boot board. If you are doing work on POST stuff, I hope that you are aware of the POST framework which is used only on the PowerPC branch right now. It'll be great if any effort in this direction could be merged under this framework. > We have modified the device lists for input/output such that it will > chain to several devices.... ex: can input data at a serial keyboard > OR at the keypad OR at the touchscreen and it will output to the > serial console AND the LCD console (and potentially a USB-client > serial console). This is all very handy for what we are doing, but > I'm not sure if its something which the generic u-boot code wants > (Wolfgang?). Its been put together with the standard list functions > and such so its not a great departure in code. I cannot speak for Wolfgang, who is on holidays by the way, but in my opinion it is a worthwhile effort. What comes to my mind immediately is to chain some output device the user can see and the logbuffer device which is available under Linux after the kernel has taken control. So please go ahead and post the patches here. Cheers Detlev -- Emacs is the way to purify your soul using garbage collection.

2 1

[U-Boot-Users] Device chaining, anyone interested?
by Woodruff, Richard 21 Aug '03

21 Aug '03

Hello, We are in the process of putting together some POST/diagnostic type code for our OMAP u-boot board. We have modified the device lists for input/output such that it will chain to several devices.... ex: can input data at a serial keyboard OR at the keypad OR at the touchscreen and it will output to the serial console AND the LCD console (and potentially a USB-client serial console). This is all very handy for what we are doing, but I'm not sure if its something which the generic u-boot code wants (Wolfgang?). Its been put together with the standard list functions and such so its not a great departure in code. Regards, Richard Woodruff.

2 1

[U-Boot-Users] Dual ethernet
by Marwan Younis 19 Aug '03

19 Aug '03

Hello, here is some information about my platform Chip: PowerQuicc II MPC8260 Ethernet PHY: Intel LXT973 (dual ethernet phy) SDRAM : 128 MB uboot version : u-boot-0.4.0 Question 1) Iam trying to add support for two ethernet ports on my board. I am not sure how to switch and test each port individually. U-boot-0.4.0 mentioned under README that it is possible to do so, by typing eth1 or eth2 to switch between the ethernet ports. I tried that but it didn't work. I just want to let you know that I did configure FCC1 and FCC2 in my INCLUDE/configs/xxxx.h file and when U-boot come out of reset, it did output the following: Net: FCC1 ETHERNET, FCC2 ETHERNET But I don't know how to verify that FCC2 is working. I am afraid iam missing something. My question is basically is how to switch between ethernet ports under u-boot-0.4.0? Thank you very much, and all comments and suggestions are welcome. regards, Marwan __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com

2 1

Re: [U-Boot-Users] hang up after start_here
by Laurent Mohin 19 Aug '03

19 Aug '03

Wolfgang, thanks for your reply. How can you bet that my initialization sequence is incomplete? I remember you that it works on 15 boards out of 16. Laurent Wolfgang Denk <wd(a)denx.de> Sent by: wd(a)denx.de 18/08/03 10:39 To: "Laurent Mohin" <laurent.mohin(a)acterna.com> cc: linuxppc-embedded(a)lists.linuxppc.org, u-boot-users(a)lists.sourceforge.net Subject: Re: [U-Boot-Users] hang up after start_here In message <OFE8EA1A87.9A7B8A06-ONC1256D86.0028950A-C1256D86.002D5CE3(a)se.wavetek.com> you wrote: > > I've debugged and found that the board hangs in start_here function and > doesn't reach the early_init function. > > Because the problem appears on only one of my boards out of 16, I suspect > a hardware problem, and because it occurs just after mmu initialisation > and caches enabling, I suspect more especially sdram accesses. > > I want to know if anybody has encountered a similar problem and if the > diagnostic was the same. This is a standard problem, which can show up in many forms. My bet is that your SDRAM initialization sequence is incomplete / broken. Remember that it is NOT sufficient to set up the mmeory controller, you must also intialize the SDRAM chips themself. 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 "What is wanted is not the will to believe, but the will to find out, which is the exact opposite." - Bertrand Russell, _Sceptical_Essays_, 1928

3 2

Re: [U-Boot-Users] hang up after start_here
by Laurent Mohin 19 Aug '03

19 Aug '03

Franck, No it's an IBM 405GPr processor which includes a SDRAM controller instead of the UPM of the MPC8XX. The mode and CAS latency of my SDRAM IC's are set by the controller itself. Once enabled, it performs an initalization procedure including issuing the mode register write command to each bank. By the way, what is the easiest way to turn MMU and caches OFF? Laurent "Frank Robbins" <Frank.Robbins(a)Analogue-Micro.com> 19/08/03 11:24 To: "Wolfgang Denk" <wd(a)denx.de>, "Laurent Mohin" <laurent.mohin(a)acterna.com> cc: <linuxppc-embedded(a)lists.linuxppc.org>, <u-boot-users(a)lists.sourceforge.net>, <wd(a)denx.de> Subject: Re: [U-Boot-Users] hang up after start_here Is this Motorola MPC8XX family? If so ... I would suggest that if you don't turn on the MMU and the cache it may work.... normally indicating a SDRAM problem What are you doing to set the mode and CAS latency on your SDRAM IC's . There is no Pure SDRAM controller on this processor family you have to do some of the work to get SDRAM running Once the cache and MMU are on then the chip will really ROCK the SDRAM hence strange failures. Regards Frank Robbins Analogue & Micro Ltd, 9 Clytha Park Road Newport South Wales NP20 4US United Kingdom (Great Britain) Email : Frank.Robbins(a)Analogue-Micro.com Email : Frank(a)Analogue-Micro.com http://www.Analogue-Micro.com Tel: 44 (0)1633 666787 Fax: 44 (0)1633 666788 ----- Original Message ----- From: "Laurent Mohin" <laurent.mohin(a)acterna.com> To: "Wolfgang Denk" <wd(a)denx.de> Cc: <linuxppc-embedded(a)lists.linuxppc.org>; <u-boot-users(a)lists.sourceforge.net>; <wd(a)denx.de> Sent: Tuesday, August 19, 2003 8:51 AM Subject: Re: [U-Boot-Users] hang up after start_here > > Wolfgang, > > thanks for your reply. > How can you bet that my initialization sequence is incomplete? > I remember you that it works on 15 boards out of 16. > > Laurent > > > > > > Wolfgang Denk <wd(a)denx.de> > Sent by: wd(a)denx.de > 18/08/03 10:39 > > > To: "Laurent Mohin" <laurent.mohin(a)acterna.com> > cc: linuxppc-embedded(a)lists.linuxppc.org, u-boot-users(a)lists.sourceforge.net > Subject: Re: [U-Boot-Users] hang up after start_here > > > In message > <OFE8EA1A87.9A7B8A06-ONC1256D86.0028950A-C1256D86.002D5CE3(a)se.wavetek.com> > you wrote: > > > > I've debugged and found that the board hangs in start_here function and > > doesn't reach the early_init function. > > > > Because the problem appears on only one of my boards out of 16, I > suspect > > a hardware problem, and because it occurs just after mmu initialisation > > and caches enabling, I suspect more especially sdram accesses. > > > > I want to know if anybody has encountered a similar problem and if the > > diagnostic was the same. > > This is a standard problem, which can show up in many forms. My bet > is that your SDRAM initialization sequence is incomplete / broken. > Remember that it is NOT sufficient to set up the mmeory controller, > you must also intialize the SDRAM chips themself. > > 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 > "What is wanted is not the will to believe, but the will to find out, > which is the exact opposite." - Bertrand Russell, _Sceptical_Essays_, > 1928 > > > ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/ >

1 0

[U-Boot-Users] mkimage multi file use?
by Tom Guilliams 18 Aug '03

18 Aug '03

I know this has been addressed before but I no longer have access to my U-Boot list archive on my PC and finding on the SourceForge list has proved troublesome such as it keeps telling me it's not accessible right now on the SoureForge page! Is there any place I can dowload the archives? I haven't been successful referencing the include/image.h file on how to use "mkimage -T multi". Any examples out there? Basically I just want to create an U-Boot image of a gzipped kernel and ramdisk. Also, I received some pointers on how to extract the U-Boot header from an image (thanks Wolfgang and Marc Singer!). Now I'm going to want to see if I can extract the kernel from a multi-file image. I think this will be similar to the header extract but any pointers are greatly appreciated. Fightin the clock on this one! Tom

2 3

[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] PATCH : fix for write protect pin manipulation for cmd_nand.c
by Woodruff, Richard 18 Aug '03

18 Aug '03

Hello, This patch allows the external command "nand write.oob xxx" to work properly for systems which have the NAND WP pin hooked up (OMAP1510 conditional). The internal function calls worked previously because the WP pin state was properly set by those call paths. Regards, Richard W.

1 0

Re: [U-Boot-Users] hang up after start_here
by S. Hebbar 18 Aug '03

18 Aug '03

Hello, I am having the exact same problem. It doesn't return to start_here label after executing RFI instruction. (linux-2.4.20) linux-2.4.20/arch/ppc/kernel/start.S ==> turn_on_mmu: mfmsr r0 ori r0,r0,MSR_DR|MSR_IR mtspr SRR1,r0 lis r0,start_here@h ori r0,r0,start_here@l mtspr SRR0,r0 SYNC RFI /* enables MMU */ I have 128Meg or SDRAM on a MPC8260 board. The initialization sequence in U-BOOT is as follows. void initdram() { #define CFG_SDRAM_BASE 0x0 #define CFG_IMMR 0x60000000 int i; int size; int cpu_type=0; volatile immap_t *immap = (immap_t *)CFG_IMMR; volatile memctl8260_t *memctl = &immap->im_memctl; volatile uchar c = 0; volatile uchar *ramaddr = (uchar *)(CFG_SDRAM_BASE) + 0x110; /* Set OR1 and OR2 values */ memctl->memc_or1 = 0xf8002940; memctl->memc_br1 = 0x00000041; /* * Quote from 8260 UM (10.4.2 SDRAM Power-On Initialization, 10-35): * * "At system reset, initialization software must set up the * programmable parameters in the memory controller banks registers * (ORx, BRx, P/LSDMR). After all memory parameters are configured, * system software should execute the following initialization sequence * for each SDRAM device. * * 1. Issue a PRECHARGE-ALL-BANKS command * 2. Issue eight CBR REFRESH commands * 3. Issue a MODE-SET command to initialize the mode register * * The initial commands are executed by setting P/LSDMR[OP] and * accessing the SDRAM with a single-byte transaction." * * The appropriate BRx/ORx registers have already been set when we * get here. The SDRAM can be accessed at the address CFG_SDRAM_BASE. */ memctl->memc_psrt = psrt; memctl->memc_mptpr = mptpr;; memctl->memc_psdmr = (ulong) psdmr | PSDMR_OP_PREA; *ramaddr = c; memctl->memc_psdmr = (ulong) psdmr | PSDMR_OP_CBRR; for (i = 0; i < 8; i++) *ramaddr = c; memctl->memc_psdmr = (ulong) psdmr | PSDMR_OP_MRW; *ramaddr = c; memctl->memc_psdmr = (ulong) psdmr | PSDMR_OP_NORM | PSDMR_RFEN; *ramaddr = c; I have turned off Data cache in U-BOOT. If I enabel D-CACHE, the code hangs in U-BOOT itself. Any help is very much appreciated. Regards, Hebbar. \ <OFE8EA1A87.9A7B8A06-ONC1256D86.0028950A-C1256D86.002D5CE3(a)se.wavetek.com> you wrote: > > I've debugged and found that the board hangs in start_here function and > doesn't reach the early_init function. > > Because the problem appears on only one of my boards out of 16, I suspect > a hardware problem, and because it occurs just after mmu initialisation > and caches enabling, I suspect more especially sdram accesses. > > I want to know if anybody has encountered a similar problem and if the > diagnostic was the same. This is a standard problem, which can show up in many forms. My bet is that your SDRAM initialization sequence is incomplete / broken. Remember that it is NOT sufficient to set up the mmeory controller, you must also intialize the SDRAM chips themself. 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 "What is wanted is not the will to believe, but the will to find out, which is the exact opposite." - Bertrand Russell, _Sceptical_Essays_, 1928 ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

1 0

RE: [U-Boot-Users] what is wrong when calloc return bogus?
by Woodruff, Richard 18 Aug '03

18 Aug '03

The heap area is not being setup properly. It appears that all of the ARM boards cpu.c and start.S were from the same root. In cpu.c _armboot_real_end is set up such that the malloc init in lib_arm/board.c's should work... It appears that the pxa's start.S diverged from the way the other ARMs did the relocation and ended up breaking this aspect of the init. So, the PXA and could change to be like the other ARM boards or ... I recall that part of a patch to board.c someone posted should result in this working for PXA. Having malloc work is important beyond getting the device_init structure up and running. Either should fairly straight forward to do. Regards, Richard W. > -----Original Message----- > From: Holger Schurig [mailto:h.schurig@mn-logistik.de] > Sent: Friday, August 15, 2003 11:39 AM > To: u-boot-users(a)lists.sourceforge.net > Subject: [U-Boot-Users] what is wrong when calloc return bogus? > > > I recently updated from u-boot 0.3.2 to CVS (0.4.5). Now blob > stopped working. > I tracked this down from device_init() to ListCreate() or NewHandle(). > > My debug output is: > > U-Boot 0.4.5 (Aug 15 2003 - 18:26:38) > > U-Boot code: A3000000 -> A300D4E0 BSS: -> A3024000 > DRAM Configuration: > Bank #0: a0000000 128 MB > Flash: 32 MB > 1 > 2 > 4 > 6 > 7 > 9 > 10 > d1 > d3 > l1 > n1 > n2 memPtr=0badc0e8 > n3 hanPtr=0badc108 > n4 > l2 > l3 0badc108 > > list_t ListCreate (int elementSize) > { > list_t list; > printf("l1\n"); > list = (list_t) (NewHandle (sizeof (ListStruct))); > /* create empty > list */ > printf("l2\n"); > if (list) { > printf("l3 %08x\n", list); > (*list)->signature = LIST_SIGNATURE; > (*list)->numItems = 0; > (*list)->listSize = 0; > (*list)->itemSize = elementSize; > (*list)->percentIncrease = > kDefaultAllocationPercentIncrease; > (*list)->minNumItemsIncrease = > kDefaultAllocationminNumItemsIncrease; > } > printf("l4\n"); > > return list; > } > > > Target is an Intel PXA255 > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites > including Data Reports, E-commerce, Portals, and Forums are > available now. Download today and enter to win an XBOX or > Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet _072303_01/01 _______________________________________________ U-Boot-Users mailing list U-Boot-Users(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users

4 3

[U-Boot-Users] [PATCH] get rid of bi_env
by Holger Schurig 18 Aug '03

18 Aug '03

The attached patch removes bi_env, bi_env_data and bi_env_crc. According to "grep -r" were nowhere used.

1 0

[U-Boot-Users] hang up after start_here
by Laurent Mohin 18 Aug '03

18 Aug '03

Hello all, I'm designing a custom board build around a 405GPr processor. I'm in my third prototype phase, and I've problem with one board which hang during Linux booting. I've debugged and found that the board hangs in start_here function and doesn't reach the early_init function. Because the problem appears on only one of my boards out of 16, I suspect a hardware problem, and because it occurs just after mmu initialisation and caches enabling, I suspect more especially sdram accesses. I want to know if anybody has encountered a similar problem and if the diagnostic was the same. Kernel version is 2.4.18 from Montavista. Thanks for help, Laurent

2 1

RE: [U-Boot-Users] what is wrong when calloc return bogus?
by Woodruff, Richard 15 Aug '03

15 Aug '03

This has come up a couple times recently. I'll agree that from a consistency standpoint it would be nice if this were same for all architectures, and it will probably end up this way, but is it really "broken", what is not currently functioning, other than a proper mapping from the documentation to reality. Regards, Richard W. > -----Original Message----- > From: Wolfgang Denk [mailto:wd@denx.de] > Sent: Friday, August 15, 2003 2:51 PM > To: Woodruff, Richard > Cc: 'Holger Schurig'; u-boot-users(a)lists.sourceforge.net > Subject: Re: [U-Boot-Users] what is wrong when calloc return bogus? > > > In message >> If the PXA is broken, then it should be fixed, but NOT by > making it like the other ARM boards which are (IMHO) > broken by design. [It's just that we didn't have enough free > resources (or volunteers???) to fix the ARM memory layout.] > > ARM still suffers from the many things ARMBoot did differently. > > 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 "In Christianity neither morality nor religion > come into contact with > reality at any point." - Friedrich Nietzsche >

2 1

[U-Boot-Users] Patches
by Jonas Larsson 15 Aug '03

15 Aug '03

I have a question regarding submitting patches. Should I send them to the mailing list or to the patch tracking system at sourceforge? I've submitted a patch to sourcforge already. The patch adds support for an environment variable 'arch' which is passed as the ARM machine number to the kernel if set. The u-boot behaviour is unchanged if 'arch' is not defined. / Jonas

3 6

[U-Boot-Users] u-boot's own boot process
by Seb James 15 Aug '03

15 Aug '03

Hi, I've got some hardware which has a problem somewhere. It's a board with a tqm823l on it and the tqm should happily boot u-boot. The module plugged into another board works fine, but in our new hardware the code hangs. I've checked out u-boot from cvs today, making it 0.4.5, and I applied a tqm8xx specific patch to boards/tqm8xx/flash.c which Wolfgang Denk posted in reply to a message a couple of days ago. I enabled debugging in config.mk and recompiled with no problems. Running the code (using gdb through an Abatron BDI2000): The problem occurs at program re-location. I set a breakpoint in cpu/mpc8xx/start.S thus: (gdb) break start.S:575 Breakpoint 2 at 0x4000231c: file /eldk/ppc_8xx/usr/src/u-boot/cpu/mpc8xx/start.S, line 575. (gdb) c Continuing. Breakpoint 2, relocate_code () at /eldk/ppc_8xx/usr/src/u-boot/cpu/mpc8xx/start.S:575 575 addi r0, r10, in_ram - _start + EXC_OFF_SYS_RESET (gdb) s 576 mtlr r0 (gdb) s 577 blr (gdb) s Program received signal SIGSTOP, Stopped (signal). 0x3ffffffc in ?? () (gdb) And you can see where the trouble occurs (console output given below). It's just at the point in start.S where u-boot is relocated from flash to RAM (correct me if that's wrong). Where's the code going from and to? In start.S I read that the code starts executing from flash, with the program counter starting at 0x100. What is boardinit? From start.S: "board_init lies at a quite high address and when the cpu has jumped there, everything is ok." Anyone have any ideas as to what might be wrong in the hardware to cause this behaviour? regards, Seb James Here's the output at the terminal: U-Boot 0.4.5 (Aug 15 2003 - 13:18:07) CPU: PPC823EZTnnB2 at 50 MHz: 16 kB I-Cache 8 kB D-Cache Board: ### No HW ID - assuming TQM8xxL DRAM: 16 MB Top of RAM usable for U-Boot at: 01000000 Reserving 204k for U-Boot at: 00fcc000 Reserving 128k for malloc() at: 00fac000 Reserving 60 Bytes for Board Info at: 00fabfc4 Reserving 52 Bytes for Global Data at: 00fabf90 Stack Pointer at: 00fabf78 New Stack Pointer is: 00fabf78 N?wr?ni?gi? A? " ?-&o?t*a?:.%?82x?F?A?H? ?e?h?d?r?i?a?d? ?#?G?t?f?a?h?b?n? ? ?i?e?@?0?%?8? #? e? (Then some more garbage is output until things stop).

1 2

RE: [U-Boot-Users] Start up problem with PPCboot 1.2.0
by Matias Sundman (TB/EAB) 15 Aug '03

15 Aug '03

Hi again, I solved the problem by flashing the two other boards with PPCboot 1.1.6 , now everything works fine. After 1.1.6 I will go for the u-boot distribution. Thanks // Matias ------------------------------------------------------- -----Original Message----- From: Matias Sundman (TB/EAB) Sent: den 14 augusti 2003 13:58 To: u-boot-users Cc: 'matias.sundman(a)sundmangroup.com' Subject: [U-Boot-Users] Start up problem with PPCboot 1.2.0 Comrades, I have three BMW (WhiteKnight) boards from Broadcom. In one of them PPCboot 1.1.6 is used and everything works fine, but on one of the others I have PPCboot 1.2.0 and I never get passed the , IP-Config: Incomplete network configuration information.... I thought the bootargs parameter should supply the Linux kernel with it's parameters, bootargs=root=/dev/nfs rw nfsroot=130.100.50.56:/tftpboot/130.100.50.55 ip=130.1 00.50.55:130.100.50.56::255.255.255.0:::off It seems to work on the 1.1.6 version though, can someone advice me what to try next? Below you can see the start-up attempt and all the environment variables used/set. Regards // Matias ---------------------------------------------------------------------------------- PPCBoot 1.2.0 (Feb 5 2003 - 17:02:59) CPU: MPC8245 Revision 16.20 at 198 MHz: 16 kB I-Cache 16 kB D-Cache Board: BMW MPC8245/KAHLUA2 - CHRP (MAP B) Built: Feb 27 2003 at 14:29:08 Local Bus at 100 MHz DRAM: 64 MB FLASH: 1 MB DiskOnChip(TM): 32MB found at address 0xff000000 In: serial Out: serial Err: serial Hit any key to stop autoboot: 0 Broadcom BCM5703 1000Base-T: bus 0, device 13, function 0: MBAR=0x80100000 BCM570x PCI Memory base address @0x80100000 eth0: Broadcom BCM5703 1000Base-T @0x80100000,node addr 0010188201a1 eth0: BCM5700 with Broadcom BCM5703 Integrated Copper transceiver found eth0: 32-bit PCI 33MHz, MTU: 1500,Rx Checksum ON ARP broadcast 1 eth0:Broadcom BCM5703 1000Base-T: 10 Mbps half duplex link up, flow control OFF TFTP from server 130.100.50.56; our IP address is 130.100.50.55 Filename 'pSystem'. Load address: 0x400000 Loading: ################################################################# ################################################## done Bytes transferred = 584472 (8eb18 hex) eth0:Broadcom BCM5703 1000Base-T,HALT,POWER DOWN,done - offline. ## Booting image at 00400000 ... Image Name: Linux-2.4.18_mvl30-lvl7 Created: 2003-07-18 9:29:45 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 584408 Bytes = 570 kB = 0 MB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Uncompressing Kernel Image ... OK Memory BAT mapping: BAT2=64Mb, BAT3=0Mb, residual: 0Mb Linux version 2.4.18_mvl30-lvl7 (uabtrg@RedHatServer) (gcc version 3.2.1 2002093 0 (MontaVista)) #1 Fri Jul 18 11:24:13 CEST 2003 Broadcom BMW Fast Ethernet Routing Switch BMW port (C) 2003 LVL7 Systems, Inc. (linville(a)lvl7.com) On node 0 totalpages: 16384 zone(0): 16384 pages. zone(1): 0 pages. zone(2): 0 pages. Kernel command line: OpenPIC Version 1.2 (1 CPUs and 139 IRQ sources) at fc040000 time_init: decrementer frequency = 24.750000 MHz Calibrating delay loop... 131.89 BogoMIPS Memory: 63088k available (1008k kernel code, 328k data, 72k init, 0k highmem) Dentry-cache hash table entries: 8192 (order: 4, 65536 bytes) Inode-cache hash table entries: 4096 (order: 3, 32768 bytes) Mount-cache hash table entries: 1024 (order: 1, 8192 bytes) Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes) Page-cache hash table entries: 16384 (order: 4, 65536 bytes) POSIX conformance testing by UNIFIX PCI: Probing PCI hardware Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket Starting kswapd Disabling the Out Of Memory Killer Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI en abled ttyS00 at 0xfc004500 (irq = 137) is a ST16650 ttyS01 at 0xfc004600 (irq = 138) is a ST16650 block: 128 slots per queue, batch=32 RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize Universal TUN/TAP device driver 1.4 (C)1999-2001 Maxim Krasnyansky MTD driver for BMW. Written by John W. Linville <linville(a)lvl7.com> bmw: Probing for BMW flash configuration... bmw: Found no BMW compatible flash configuration... Macintosh non-volatile memory driver v1.0 Broadcom Gigabit Ethernet Driver bcm5700 ver. 3.0.7 (07/17/02) eth0: Broadcom BCM5703 1000Base-T found at mem bfff0000, IRQ 17, node addr 00101 88201a1 eth0: Broadcom BCM5703 Integrated Copper transceiver found eth0: Scatter-gather OFF, 64-bit DMA OFF, Tx Checksum ON, Rx Checksum ON NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 4096 bind 8192) IP-Config: Incomplete network configuration information. NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. Root-NFS: No NFS server available, giving up. VFS: Unable to mount root fs via NFS, trying floppy. VFS: Cannot open root device "" or 02:00 Please append a correct "root=" boot option Kernel panic: VFS: Unable to mount root fs on 02:00 =>printenv baudrate=9600 clocks_in_mhz=1 ethaddr=00:10:18:82:01:A1 lan_ifname=bcm0 lan_ifnames= lan_hwnames= lan_hwaddr= wan_ifname=eth0 wan_hwname= timer_interval=3600 ntp_server= log_level=0 time_zone=PST8PDT upnp_enable=0 os_server=http://router:kilroy@64.162.141.122 stats_server=http://router:kilroy@64.162.141.122/cgi-bin/stats.pl console_loglevel=7 lan_proto=dhcp lan_ipaddr=192.168.1.1 lan_netmask=255.255.255.0 lan_stp=0 wan_hostname= wan_domain= static_route= filter_ip= filter_tcp= filter_udp= filter_mac= forward_tcp= forward_udp= dmz_ipaddr= http_username=router http_passwd=kilroy http_wanport=8080 http_lanport=80 pppoe_ifname= pppoe_username= pppoe_passwd= pppoe_idletime=60 pppoe_keepalive=0 pppoe_demand=0 pppoe_mru=1500 pppoe_mtu=1500 wl_ssid=Broadcom wl_country=USA wl_closed=0 wl_wep=off wl_auth=0 wl_key=1 wl_key1= wl_key2= wl_key3= wl_key4= wl_mac= wl_macmode=allow d11b_channel=11 d11b_rate=0 d11b_rateset=default d11b_frag=2346 d11b_rts=2347 d11b_dtim=3 d11b_bcn=100 d11b_plcphdr=long d11a_channel=64 d11a_rate=0 d11a_rateset=default d11a_frag=2346 d11a_rts=2347 d11a_dtim=3 d11a_bcn=100 d11g_channel=11 d11g_rate=0 d11g_rateset=default d11g_frag=2346 d11g_rts=2347 d11g_dtim=3 d11g_bcn=100 restore_defaults=0 wan_dns=130.100.241.150 130.100.76.22 130.100.76.32 wan_wins=147.214.112.67 153.88.193.201 wan_lease=604800 wan_ipaddr=0.0.0.0 wan_netmask=0.0.0.0 wan_gateway=0.0.0.0 os_name=linux os_version=2.4.19-rc3 filesize=25994a dhcp_start=130.100.50.56 dhcp_end=130.100.50.56 gw=255.255.255.255 nfsroot=130.100.50.56:/tftpboot/130.100.50.55 root=/dev/nfs rw bootdelay=5 bootfile=pSystem netmask=255.255.255.0 ipaddr=130.100.50.55 serverip=130.100.50.56 rootpath=/tftpboot/130.100.50.55 bootcmd=tftpboot 00400000 ; bootm bootargs=root=/dev/nfs rw nfsroot=130.100.50.56:/tftpboot/130.100.50.55 ip=130.1 00.50.55:130.100.50.56::255.255.255.0:::off stdin=serial stdout=serial stderr=serial Environment size: 1903/8172 bytes => ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ U-Boot-Users mailing list U-Boot-Users(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users

2 1

RE: [U-Boot-Users] examples programs
by Dave.Stoddart＠aculab.com 15 Aug '03

15 Aug '03

Hi Wolfgang, Thanks for the comments. OK, found the section on Memory Management, do remember seeing it a while ago. But it doesn't explain my problem. I have also built the code into u-boot, and it runs just fine. The only thing I can think that is out of the ordinary is a large static array of short values, (2-3K) which get downloaded to an attached DSP. Its not the end of the world if it doesn't work, but its been bugging me (sorry!!) for a week or two. Thanks David

1 0

[U-Boot-Users] examples programs
by Dave.Stoddart＠aculab.com 15 Aug '03

15 Aug '03

Hi Folks, I am using U-Boot 0.4.0 with an MPC8245 processor with 64MBytes of SDRAM. The hardware appears to work fine, as we can load / run U-Boot and then run Embedded Linux without a problem. I have written some simple hardware test programs, again without a problem, using the examples/hello_world.c as a starting point. However, as they get more complex, i.e. more variables and larger, the program crashes, with odd messages coming out of mon_printf commands. It looks to me as though the stack is crashing. If I make the LOAD_ADDR in the Makefile 0x03000000, originally the default location 0x00040004, i.e. much higher up than the original, the test program works fine and returns to U-Boot without error. Has anybody else seen anything like this? Or can anybody tell me where the stack is? I have looked at the documentation, and cannot see anywhere that describes the memory layout when U-Boot is running. Regards David Stoddart Aculab PLC

2 1