May 2003 - U-Boot

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

17 Mar '04

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

3 2

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

17 Mar '04

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

2 1

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

28 Aug '03

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

2 1

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

30 May '03

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

2 1

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

30 May '03

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

1 0

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

30 May '03

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

1 0

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

30 May '03

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

2 3

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

30 May '03

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

1 0

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

29 May '03

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

1 0

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

29 May '03

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

2 2

RE: [U-Boot-Users] interrupts.s/udelay accuracy.
by Woodruff, Richard 29 May '03

29 May '03

Perhaps its not worth worrying about in this context. Several of the ports use a simple split /1000 /1000 along with CFG_HZ to convert microseconds to ticks. When I grepped the config files I saw a pretty wide range of raw frequency's including some below the megahertz range which the /1000's are normalizing for. A simple grep of the sources also shows many functions use udelay with input ranges from 1 to 100,000,000. I called out ethernet, but I was more wondering about protocols which might like to delay. In fairness most if not all which use this correction are in the mhz range. In my case I can set the tick rate for the free running decrementer in the KHz range or in the Mhz range. To allow for a variable CFG_HZ setting it would be nice if the normalization did not assume megahertz, and nice to allow for a wide udelay input, such that tmo *= CFG_HZ, would not overflow a 32 bit number. I had used some code in the past which did use long long's to normalize from various input levels, sec/milli/micro/nano, and converted it to clock ticks with out dropping bits. When I reached the point of wondering if I should use a bit more code, I started to wonder if it was worth my time to even do it...thus I asked if anything really needed it. Regards, Richard W. > > So - why are you asking? There is no problem with the accuracy of > udelay() etc. > > > enough of the basics ported for my arm925/omap based board > such that > > it comes to a u-boot shell, and things like sleep x work....I was > > thinking about moving on to getting my ethernet device > working, and am > > a little > > What has udelay() or other timing functions to do with ethernet? > > > uneasy about the way I (and it appears several others) have > hacked the > > time conversions. Does gcc provide some nice 64 bit integer > > manipulation libraries which aren't huge? If so I'd be tempted to > > bring in some code > > Which sort of libraries do you need? If you really think you > must you could use "log long" data types, but I don't see any > need for that. > > > which does the right thing and doesn't have to worry about integer > > over/under flows. > > What exactly are you talking about? > > Maybe you should explain the problem you are trying to solve. > I feel you must be on a wrong track... > > 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 I can't say I've ever been lost, but I was > bewildered once for three > days. - Daniel Boone (Attributed) >

1 0

[U-Boot-Users] interrupts.s/udelay accuracy.
by Woodruff, Richard 29 May '03

29 May '03

Hello, About how accurate in practice does the udelay() & other time base functions have to be? especially for ethernet/networking devices? I've currently got enough of the basics ported for my arm925/omap based board such that it comes to a u-boot shell, and things like sleep x work....I was thinking about moving on to getting my ethernet device working, and am a little uneasy about the way I (and it appears several others) have hacked the time conversions. Does gcc provide some nice 64 bit integer manipulation libraries which aren't huge? If so I'd be tempted to bring in some code which does the right thing and doesn't have to worry about integer over/under flows. Regards/Thanks, Richard W.

2 1

[U-Boot-Users] patches
by Matthew S. McClintock 29 May '03

29 May '03

Here are some patches.. u-boot-startchg.patch: this patches changes what I was talking about in the message (whoops, it was an html message) I sent to the list earlier. u-boot-utxchg.patch: these are changes for our board that brings u-boot upto date with what we have here If you have any questions don't hesistate to ask. Thanks, Matthew diff -urN ../u-boot-pristine/cpu/mpc824x/start.S ./cpu/mpc824x/start.S --- ../u-boot-pristine/cpu/mpc824x/start.S 2003-05-22 17:53:09.000000000 -0500 +++ ./cpu/mpc824x/start.S 2003-05-28 14:47:27.620109000 -0500 @@ -542,7 +542,7 @@ mr r10, r5 /* Save copy of Destination Address */ mr r3, r5 /* Destination Address */ -#ifdef DEBUG +#ifdef CFG_BOOT_IMAGE_FROM_RAM lis r4, CFG_SDRAM_BASE@h /* Source Address */ ori r4, r4, CFG_SDRAM_BASE@l #else diff -urN ../u-boot-pristine/board/utx8245/flash.c ./board/utx8245/flash.c --- ../u-boot-pristine/board/utx8245/flash.c 2002-11-02 18:47:04.000000000 -0600 +++ ./board/utx8245/flash.c 2003-05-28 14:38:13.002469000 -0500 @@ -2,11 +2,6 @@ * (C) Copyright 2001 * Wolfgang Denk, DENX Software Engineering, wd(a)denx.de. * - * (C) Copyright 2002 - * Gregory E. Allen, gallen(a)arlut.utexas.edu - * Matthew E. Karger, karger(a)arlut.utexas.edu - * Applied Research Laboratories, The University of Texas at Austin - * * See file CREDITS for list of people who contributed to this * project. * @@ -45,25 +40,17 @@ # endif #endif -#define FLASH_BANK_SIZE 0x200000 +#define FLASH_BANK_SIZE ((uint)(16 * 1024 * 1024)) /* max 16Mbyte */ #define MAIN_SECT_SIZE 0x10000 #define SECT_SIZE_32KB 0x8000 #define SECT_SIZE_8KB 0x2000 flash_info_t flash_info[CFG_MAX_FLASH_BANKS]; -static int write_word (flash_info_t *info, ulong dest, ulong data); - -static __inline__ unsigned long get_msr(void) -{ unsigned long msr; - __asm__ __volatile__ ("mfmsr %0" : "=r" (msr) :); - return msr; -} - -static __inline__ void set_msr(unsigned long msr) -{ - __asm__ __volatile__ ("mtmsr %0" : : "r" (msr)); -} +static int write_data (flash_info_t *info, ulong dest, ulong *data); +static void write_via_fpu(vu_long *addr, ulong *data); +static __inline__ unsigned long get_msr(void); +static __inline__ void set_msr(unsigned long msr); /*flash command address offsets*/ #define ADDR0 (0x555) @@ -73,39 +60,87 @@ #define FLASH_WORD_SIZE unsigned char /*---------------------------------------------------------------------*/ -/*#define DEBUG_FLASH 1 */ +//#define DEBUG_FLASH 1 /*---------------------------------------------------------------------*/ unsigned long flash_init(void) { - int i, j; - ulong size = 0; + int i; /* flash bank counter */ + int j; /* flash device sector counter */ + int k; /* flash size calculation loop counter */ + int N; /* pow(2,N) is flash size, but we don't have <math.h> */ + ulong total_size = 0, device_size = 1; unsigned char manuf_id, device_id; - for (i = 0; i < CFG_MAX_FLASH_BANKS; i++) + for (i = 0; i < CFG_MAX_FLASH_BANKS; i++) { vu_char *addr = (vu_char *)(CFG_FLASH_BASE + i * FLASH_BANK_SIZE); - addr[0x555] = 0xAA; /* 3 cycles to read device info. See */ - addr[0x2AA] = 0x55; /* AM29LV116D datasheet for list of */ - addr[0x555] = 0x90; /* available commands. */ - - manuf_id = addr[0]; - device_id = addr[1]; - + addr[0x555] = 0xAA; /* get manuf/device info command */ + addr[0x2AA] = 0x55; /* 3-cycle command */ + addr[0x555] = 0x90; + + manuf_id = addr[0]; /* read back manuf/device info */ + device_id = addr[1]; + + addr[0x55] = 0x98; /* CFI command */ + N = addr[0x27]; /* read back device_size = pow(2,N) */ + + for (k = 0; k < N; k++) /* calculate device_size = pow(2,N) */ + device_size *= 2; + + flash_info[i].size = device_size; + flash_info[i].sector_count = CFG_MAX_FLASH_SECT; + #if defined DEBUG_FLASH printf("manuf_id = %x, device_id = %x\n", manuf_id, device_id); -#endif - - if ( (manuf_id == (uchar)(AMD_MANUFACT)) && - ( device_id == AMD_ID_LV116DT)) +#endif + /* find out what kind of flash we are using */ + if ((manuf_id == (uchar)(AMD_MANUFACT)) + && (device_id == AMD_ID_LV033C)) + { + flash_info[i].flash_id = ((FLASH_MAN_AMD & FLASH_VENDMASK) << 16) | + (FLASH_AM033C & FLASH_TYPEMASK); + + /* set individual sector start addresses */ + for (j = 0; j < flash_info[i].sector_count; j++) + { + flash_info[i].start[j] = (CFG_FLASH_BASE + i * FLASH_BANK_SIZE + + j * MAIN_SECT_SIZE); + } + } + + else if ((manuf_id == (uchar)(AMD_MANUFACT)) && + (device_id == AMD_ID_LV116DT)) { flash_info[i].flash_id = ((FLASH_MAN_AMD & FLASH_VENDMASK) << 16) | - (AMD_ID_LV116DT & FLASH_TYPEMASK); - } else { + (FLASH_AM160T & FLASH_TYPEMASK); + + /* set individual sector start addresses */ + for (j = 0; j < flash_info[i].sector_count; j++) + { + flash_info[i].start[j] = (CFG_FLASH_BASE + i * FLASH_BANK_SIZE + + j * MAIN_SECT_SIZE); + + if (j < (CFG_MAX_FLASH_SECT - 3)) + flash_info[i].start[j] = (CFG_FLASH_BASE + i * FLASH_BANK_SIZE + + j * MAIN_SECT_SIZE); + + else if (j == (CFG_MAX_FLASH_SECT - 3)) + flash_info[i].start[j] = (flash_info[i].start[j-1] + + SECT_SIZE_32KB); + + else + flash_info[i].start[j] = (flash_info[i].start[j-1] + + SECT_SIZE_8KB); + } + } + + else + { flash_info[i].flash_id = FLASH_UNKNOWN; - addr[0] = (long)0xFFFFFFFF; + addr[0] = 0xFFFFFFFF; goto Done; } @@ -113,32 +148,11 @@ printf ("flash_id = 0x%08lX\n", flash_info[i].flash_id); #endif - addr[0] = (long)0xFFFFFFFF; - - flash_info[i].size = FLASH_BANK_SIZE; - flash_info[i].sector_count = CFG_MAX_FLASH_SECT; + addr[0] = 0xFFFFFFFF; + memset(flash_info[i].protect, 0, CFG_MAX_FLASH_SECT); - - for (j = 0; j < flash_info[i].sector_count; j++) - { - - if (j < (CFG_MAX_FLASH_SECT - 3) ) - - flash_info[i].start[j] = CFG_FLASH_BASE + i * FLASH_BANK_SIZE + - j * MAIN_SECT_SIZE; - - else if (j == (CFG_MAX_FLASH_SECT - 3) ) - - flash_info[i].start[j] = flash_info[i].start[j-1] + SECT_SIZE_32KB; - - - else - - flash_info[i].start[j] = flash_info[i].start[j-1] + SECT_SIZE_8KB; - - } - - size += flash_info[i].size; + + total_size += flash_info[i].size; } /* Protect monitor and environment sectors @@ -149,12 +163,12 @@ #endif #if (CFG_ENV_IS_IN_FLASH == 1) && defined(CFG_ENV_ADDR) - flash_protect(FLAG_PROTECT_SET, CFG_ENV_ADDR, + flash_protect(FLAG_PROTECT_SET, CFG_ENV_ADDR, CFG_ENV_ADDR + CFG_ENV_SIZE - 1, &flash_info[0]); #endif Done: - return size; + return total_size; } /*----------------------------------------------------------------------- @@ -179,12 +193,13 @@ switch(info->flash_id & FLASH_TYPEMASK) { - case FLASH_AM040: type = "AM29F040B (512K * 8, uniform sector size)"; break; + case FLASH_AM033C: type = "AM29LV033C (32 Mbit, uniform sector size)"; break; + case FLASH_AM160T: type = "AM29LV160T (16 Mbit, top boot sector)"; break; + case FLASH_AM040: type = "AM29F040B (512K * 8, uniform sector size)"; break; case FLASH_AM400B: type = "AM29LV400B (4 Mbit, bottom boot sect)"; break; case FLASH_AM400T: type = "AM29LV400T (4 Mbit, top boot sector)"; break; case FLASH_AM800B: type = "AM29LV800B (8 Mbit, bottom boot sect)"; break; case FLASH_AM800T: type = "AM29LV800T (8 Mbit, top boot sector)"; break; - case FLASH_AM160T: type = "AM29LV160T (16 Mbit, top boot sector)"; break; case FLASH_AM320B: type = "AM29LV320B (32 Mbit, bottom boot sect)"; break; case FLASH_AM320T: type = "AM29LV320T (32 Mbit, top boot sector)"; break; case FLASH_STM800AB: type = "M29W800AB (8 Mbit, bottom boot sect)"; break; @@ -284,7 +299,7 @@ sh8b = 3; else sh8b = 0; - + /* Disable interrupts which might cause a timeout here */ flag = disable_interrupts(); @@ -295,9 +310,9 @@ addr[ADDR1 << sh8b] = (FLASH_WORD_SIZE)0x00550055; /* Start erase on unprotected sectors */ - for (sect = s_first; sect<=s_last; sect++) + for (sect = s_first; sect<=s_last; sect++) { - if (info->protect[sect] == 0) + if (info->protect[sect] == 0) { /* not protected */ addr = (FLASH_WORD_SIZE *)(info->start[0] + ( (info->start[sect] - info->start[0]) << sh8b)); @@ -312,10 +327,10 @@ addr[0] = (FLASH_WORD_SIZE)0x00500050; /* block erase */ udelay(30000); /* wait 30 ms */ } - + else addr[0] = (FLASH_WORD_SIZE)0x00300030; /* sector erase */ - + l_sect = sect; } } @@ -489,3 +504,22 @@ } /*----------------------------------------------------------------------- */ +static void write_via_fpu(vu_long *addr, ulong *data) +{ + __asm__ __volatile__ ("lfd 1, 0(%0)" : : "r" (data)); + __asm__ __volatile__ ("stfd 1, 0(%0)" : : "r" (addr)); +} +/*----------------------------------------------------------------------- + */ +static __inline__ unsigned long get_msr(void) +{ + unsigned long msr; + + __asm__ __volatile__ ("mfmsr %0" : "=r" (msr) :); + return msr; +} + +static __inline__ void set_msr(unsigned long msr) +{ + __asm__ __volatile__ ("mtmsr %0" : : "r" (msr)); +} diff -urN ../u-boot-pristine/board/utx8245/utx8245.c ./board/utx8245/utx8245.c --- ../u-boot-pristine/board/utx8245/utx8245.c 2003-02-14 05:22:40.000000000 -0600 +++ ./board/utx8245/utx8245.c 2003-05-28 14:56:55.117581000 -0500 @@ -30,6 +30,7 @@ #include <mpc824x.h> #include <asm/processor.h> #include <asm/io.h> +#include <asm/mmu.h> #include <pci.h> #define SAVE_SZ 32 @@ -53,9 +54,15 @@ volatile ulong *addr; ulong save[SAVE_SZ]; ulong val, ret = 0; - +/* + write_bat(IBAT1, ((CFG_MAX_RAM_SIZE/2) | BATU_BL_256M | BATU_VS | BATU_VP), + ( (CFG_MAX_RAM_SIZE/2)| BATL_PP_10 | BATL_MEMCOHERENCE)); + + write_bat(DBAT1, ((CFG_MAX_RAM_SIZE/2) | BATU_BL_256M | BATU_VS | BATU_VP), + ( (CFG_MAX_RAM_SIZE/2)| BATL_PP_10 | BATL_MEMCOHERENCE)); +*/ for (i=0; i<SAVE_SZ; i++) {save[i] = 0;} /* clear table */ - + for (i=0, cnt=(CFG_MAX_RAM_SIZE / sizeof(long)) >> 1; cnt > 0; cnt >>= 1) { addr = (volatile ulong *)base + cnt; @@ -78,7 +85,7 @@ addr = (volatile ulong *)base + cnt; val = *addr; *addr = save[--i]; - if (val != ~cnt) + if (val != ~cnt) { ulong new_bank0_end = cnt * sizeof(long) - 1; ulong mear1 = mpc824x_mpc107_getreg(MEAR1); @@ -110,16 +117,16 @@ */ static struct pci_config_table pci_utx8245_config_table[] = { -#ifndef CONFIG_PCI_PNP - { PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, - pci_cfgfunc_config_device, { PCI_ENET0_IOADDR, - PCI_ENET0_MEMADDR, +#ifndef CONFIG_PCI_PNP + { PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, 0x0C, PCI_ANY_ID, + pci_cfgfunc_config_device, { PCI_ENET0_IOADDR, + PCI_ENET0_MEMADDR, PCI_COMMAND_MEMORY | PCI_COMMAND_MASTER }}, - { PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, - pci_cfgfunc_config_device, { PCI_FIREWIRE_IOADDR, - PCI_FIREWIRE_MEMADDR, + { PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, 0x0B, PCI_ANY_ID, + pci_cfgfunc_config_device, { PCI_FIREWIRE_IOADDR, + PCI_FIREWIRE_MEMADDR, PCI_COMMAND_MEMORY | PCI_COMMAND_MASTER }}, -#endif /*CONFIG_PCI_PNP*/ +#endif /*CONFIG_PCI_PNP*/ { } }; @@ -129,12 +136,20 @@ if (PCI_DEV(dev) == 11) /* assign serial interrupt line 9 (int25) to FireWire */ pci_hose_write_config_byte(hose, dev, PCI_INTERRUPT_LINE, 25); - + else if (PCI_DEV(dev) == 12) /* assign serial interrupt line 8 (int24) to Ethernet */ pci_hose_write_config_byte(hose, dev, PCI_INTERRUPT_LINE, 24); + + else if (PCI_DEV(dev) == 14) + /* assign serial interrupt line 0 (int16) to PMC slot 0 */ + pci_hose_write_config_byte(hose, dev, PCI_INTERRUPT_LINE, 16); + + else if (PCI_DEV(dev) == 15) + /* assign serial interrupt line 1 (int17) to PMC slot 1 */ + pci_hose_write_config_byte(hose, dev, PCI_INTERRUPT_LINE, 17); } - + static struct pci_controller utx8245_hose = { #ifndef CONFIG_PCI_PNP config_table: pci_utx8245_config_table, @@ -146,7 +161,7 @@ void pci_init_board (void) { pci_mpc824x_init(&utx8245_hose); - + icache_enable(); } diff -urN ../u-boot-pristine/include/configs/utx8245.h ./include/configs/utx8245.h --- ../u-boot-pristine/include/configs/utx8245.h 2002-11-02 18:34:34.000000000 -0600 +++ ./include/configs/utx8245.h 2003-05-28 15:08:35.984311000 -0500 @@ -51,16 +51,39 @@ #define CONFIG_UTX8245 1 #define DEBUG 1 +#define CONFIG_IDENT_STRING " [UTX5] " + #define CONFIG_CONS_INDEX 1 #define CONFIG_BAUDRATE 57600 #define CFG_BAUDRATE_TABLE { 9600, 19200, 38400, 57600, 115200 } -#define CONFIG_BOOTDELAY 5 +#define CONFIG_BOOTDELAY 2 #define CONFIG_AUTOBOOT_PROMPT "autoboot in %d seconds\n" -#define CONFIG_BOOTCOMMAND "bootm FF920000 FF800000" /* autoboot command */ +#define CONFIG_BOOTCOMMAND "run nfsboot" /* autoboot command */ #define CONFIG_BOOTARGS "root=/dev/ram console=ttyS0,57600" /* RAMdisk */ -#define CONFIG_ETHADDR 41:52:4c:61:00:01 /* MAC address */ -#define CONFIG_SERVERIP 10.8.17.105 +#define CONFIG_ETHADDR 00:AA:00:14:00:05 /* UTX5 */ +#define CONFIG_SERVERIP 10.8.17.105 /* Spree */ +#define CFG_TFTP_LOADADDR 10000 + +#define CONFIG_EXTRA_ENV_SETTINGS \ + "kernel_addr=FFA00000\0" \ + "ramdisk_addr=FF800000\0" \ + "ppcboot_startaddr=FFB00000\0" \ + "ppcboot_endaddr=FFB2FFFF\0" \ + "nfsargs=setenv bootargs console=ttyS0,\$(baudrate) root=/dev/nfs rw \ +nfsroot=\$(nfsrootip):\$(rootpath) ip=dhcp\0" \ + "ramargs=setenv bootargs console=ttyS0,\$(baudrate) root=/dev/ram0\0" \ + "smargs=setenv bootargs console=ttyS0,\$(baudrate) root=/dev/mtdblock1 ro\0" \ + "fwargs=setenv bootargs console=ttyS0,\$(baudrate) root=/dev/sda2 ro\0" \ + "nfsboot=run nfsargs\;bootm \$(kernel_addr)\0" \ + "ramboot=run ramargs\;bootm \$(kernel_addr) \$(ramdisk_addr)\0" \ + "smboot=run smargs\;bootm \$(kernel_addr) \$(ramdisk_addr)\0" \ + "fwboot=run fwargs\;bootm \$(kernel_addr) \$(ramdisk_addr)\0" \ + "update_ppcboot=tftp \$(loadaddr) /bdi2000/./ppcboot.bin;protect off \ +\$(ppcboot_startaddr) \$(ppcboot_endaddr);era \$(ppcboot_startaddr) \ +\$(ppcboot_endaddr);cp.b \$(loadaddr) \$(ppcboot_startaddr) \$(filesize);\ +protect on \$(ppcboot_startaddr) \$(ppcboot_endaddr)" + #define CONFIG_ENV_OVERWRITE #define CONFIG_COMMANDS (CFG_CMD_DFL | CFG_CMD_BDI | CFG_CMD_PCI \ @@ -70,7 +93,8 @@ | CFG_CMD_IMI | CFG_CMD_CACHE \ | CFG_CMD_RUN | CFG_CMD_ECHO \ | CFG_CMD_REGINFO | CFG_CMD_NET\ - | CFG_CMD_DHCP) + | CFG_CMD_DHCP | CFG_CMD_I2C \ + | CFG_CMD_DATE) /* This must be included AFTER the definition of CONFIG_COMMANDS (if any) */ @@ -80,9 +104,9 @@ /* * Miscellaneous configurable options */ -#define CFG_LONGHELP /* undef to save memory */ -#define CFG_PROMPT "=> " /* Monitor Command Prompt */ -#define CFG_CBSIZE 256 /* Console I/O Buffer Size */ +#define CFG_LONGHELP /* undef to save memory */ +#define CFG_PROMPT "=> " /* Monitor Command Prompt */ +#define CFG_CBSIZE 256 /* Console I/O Buffer Size */ /* Print Buffer Size */ #define CFG_PBSIZE (CFG_CBSIZE + sizeof(CFG_PROMPT) + 16) @@ -101,12 +125,20 @@ #define CONFIG_PCI_SCAN_SHOW #define CONFIG_NET_MULTI #define CONFIG_EEPRO100 +#define CONFIG_EEPRO100_SROM_WRITE + +#define PCI_ENET0_IOADDR 0xF0000000 +#define PCI_ENET0_MEMADDR 0xF0000000 -#define PCI_ENET0_IOADDR 0x80000000 +#define PCI_FIREWIRE_IOADDR 0xF1000000 +#define PCI_FIREWIRE_MEMADDR 0xF1000000 +/* +#define PCI_ENET0_IOADDR 0xFE000000 #define PCI_ENET0_MEMADDR 0x80000000 + #define PCI_FIREWIRE_IOADDR 0x81000000 #define PCI_FIREWIRE_MEMADDR 0x81000000 - +*/ /*----------------------------------------------------------------------- * Start addresses for the final memory configuration @@ -114,12 +146,13 @@ * Please note that CFG_SDRAM_BASE _must_ start at 0 */ #define CFG_SDRAM_BASE 0x00000000 -#define CFG_MAX_RAM_SIZE 0x10000000 /* amount of SDRAM */ +#define CFG_MAX_RAM_SIZE 0x10000000 /* 256MB */ +//#define CFG_VERY_BIG_RAM 1 - -/* even though FLASHP_BASE is FF800000, with 2MB on RCS0, the - * reset vector is actually located at FF800100, but the 8245 - * takes care of us. +/* FLASH_BASE is FF800000, with 4MB on RCS0, but the reset vector + * is actually located at FFF00100. Therefore, PPCBoot is + * physically located at 0xFFB0_0000, but is also mirrored at + * 0xFFF0_0000. */ #define CFG_RESET_ADDRESS 0xFFF00100 @@ -130,33 +163,41 @@ #define CFG_MONITOR_LEN (256 << 10) /* Reserve 256 kB for Monitor */ #define CFG_MALLOC_LEN (128 << 10) /* Reserve 128 kB for malloc() */ -/*#define CFG_DRAM_TEST 1 */ +//#define CFG_DRAM_TEST 1 #define CFG_MEMTEST_START 0x00003000 /* memtest works on 0...256 MB */ -#define CFG_MEMTEST_END 0x0ff8ffa8 /* in SDRAM, skips exception */ - /* vectors and U-Boot */ +#define CFG_MEMTEST_END 0x0ff8ffa7 /* in SDRAM, skips exception */ + /* vectors and PPCBoot */ /*-------------------------------------------------------------------- * Definitions for initial stack pointer and data area *------------------------------------------------------------------*/ -#define CFG_GBL_DATA_SIZE 128 /* Size in bytes reserved for */ +#define CFG_INIT_DATA_SIZE 128 /* Size in bytes reserved for */ /* initial data */ #define CFG_INIT_RAM_ADDR 0x40000000 #define CFG_INIT_RAM_END 0x1000 +#define CFG_INIT_DATA_OFFSET (CFG_INIT_RAM_END - CFG_INIT_DATA_SIZE) +#define CFG_GBL_DATA_SIZE 128 #define CFG_GBL_DATA_OFFSET (CFG_INIT_RAM_END - CFG_GBL_DATA_SIZE) /*-------------------------------------------------------------------- * NS16550 Configuration *------------------------------------------------------------------*/ -#define CFG_NS16550 +#define CFG_NS16550 #define CFG_NS16550_SERIAL #define CFG_NS16550_REG_SIZE 1 -#define CFG_NS16550_CLK get_bus_freq(0) +#if (CONFIG_CONS_INDEX == 1 || CONFIG_CONS_INDEX == 2) +# define CFG_NS16550_CLK get_bus_freq(0) +#else +# define CFG_NS16550_CLK 33000000 +#endif #define CFG_NS16550_COM1 (CFG_EUMB_ADDR + 0x4500) #define CFG_NS16550_COM2 (CFG_EUMB_ADDR + 0x4600) +#define CFG_NS16550_COM3 0xFF000000 +#define CFG_NS16550_COM4 0xFF000008 /*-------------------------------------------------------------------- * Low Level Configuration Settings @@ -168,60 +209,83 @@ #define CONFIG_SYS_CLK_FREQ 33000000 #define CFG_HZ 1000 -#define CFG_ETH_DEV_FN 0x7800 -#define CFG_ETH_IOBASE 0x00104000 +//#define CFG_ETH_DEV_FN 0x7800 +//#define CFG_ETH_IOBASE 0x00104000 + +/*-------------------------------------------------------------------- + * I2C Configuration + *------------------------------------------------------------------*/ +#if 1 +#define CONFIG_HARD_I2C 1 /* To enable I2C support */ +#undef CONFIG_SOFT_I2C /* I2C bit-banged */ +#define CFG_I2C_SPEED 400000 /* I2C speed and slave address */ +#define CFG_I2C_SLAVE 0x7F +#endif +#define CONFIG_RTC_PCF8563 1 /* enable I2C support for */ + /* Philips PCF8563 RTC */ +#define CFG_I2C_RTC_ADDR 0x51 /* Philips PCF8563 RTC address */ /*-------------------------------------------------------------------- * Memory Control Configuration Register values * - see sec. 4.12 of MPC8245 UM *------------------------------------------------------------------*/ -/* MCCR1 */ +/**** MCCR1 ****/ #define CFG_ROMNAL 0 -#define CFG_ROMFAL 2 /* (tacc=70ns)*mem_freq - 2 */ -#define CFG_BANK0_ROW 2 /* SDRAM bank 7-0 row address */ -#define CFG_BANK1_ROW 2 /* bit count */ -#define CFG_BANK2_ROW 0 -#define CFG_BANK3_ROW 0 -#define CFG_BANK4_ROW 0 +#define CFG_ROMFAL 10 /* (tacc=70ns)*mem_freq - 2, + mem_freq = 100MHz */ + +#define CFG_BANK7_ROW 0 /* SDRAM bank 7-0 row address */ +#define CFG_BANK6_ROW 0 /* bit count */ #define CFG_BANK5_ROW 0 -#define CFG_BANK6_ROW 0 -#define CFG_BANK7_ROW 0 +#define CFG_BANK4_ROW 0 +#define CFG_BANK3_ROW 0 +#define CFG_BANK2_ROW 0 +#define CFG_BANK1_ROW 2 +#define CFG_BANK0_ROW 2 -/* MCCR2, refresh interval clock cycles */ +/**** MCCR2, refresh interval clock cycles ****/ #define CFG_REFINT 480 /* 33 MHz SDRAM clock was 480 */ -/* Burst To Precharge. Bits of this value go to MCCR3 and MCCR4 */ +/* Burst To Precharge. Bits of this value go to MCCR3 and MCCR4. */ #define CFG_BSTOPRE 1023 /* burst to precharge[0..9], */ /* sets open page interval */ - -/* MCCR3 */ -#define CFG_REFREC 5 /* Refresh to activate interval, trc */ - -/* MCCR4 */ + +/**** MCCR3 ****/ +#define CFG_REFREC 7 /* Refresh to activate interval, trc */ + +/**** MCCR4 ****/ #define CFG_PRETOACT 2 /* trp */ -#define CFG_ACTTOPRE 7 /* trcd + (burst length - 1) + tdrl */ +#define CFG_ACTTOPRE 7 /* trcd + (burst length - 1) + trdl */ #define CFG_SDMODE_CAS_LAT 3 /* SDMODE CAS latancy */ #define CFG_SDMODE_WRAP 0 /* SDMODE wrap type, sequential */ #define CFG_ACTORW 2 /* trcd min */ #define CFG_DBUS_SIZE2 1 /* set for 8-bit RCS1, clear for 32,64 */ #define CFG_REGISTERD_TYPE_BUFFER 1 -#define CFG_EXTROM 1 +#define CFG_EXTROM 0 /* we don't need extended ROM space */ #define CFG_REGDIMM 0 /* calculate according to formula in sec. 6-22 of 8245 UM */ #define CFG_PGMAX 50 /* how long the 8245 retains the */ /* currently accessed page in memory */ /* was 45 */ - + #define CFG_SDRAM_DSCD 0x20 /* SDRAM data in sample clock delay - note */ - /* bottom 3 bits MUST be 0 */ + /* bits 7,6, and 3-0 MUST be 0 */ +#if 0 #define CFG_DLL_MAX_DELAY 0x04 +#else +#define CFG_DLL_MAX_DELAY 0 +#endif +#if 0 /* need for 33MHz SDRAM */ #define CFG_DLL_EXTEND 0x80 +#else +#define CFG_DLL_EXTEND 0 +#endif #define CFG_PCI_HOLD_DEL 0x20 - + /* Memory bank settings. * Only bits 20-29 are actually used from these values to set the @@ -255,29 +319,34 @@ #define CFG_BANK7_END 0x3fffffff #define CFG_BANK7_ENABLE 0 -/*-------------------------------------------------------------------- - * 4.4 - Output Driver Control Register - *------------------------------------------------------------------*/ +//-------------------------------------------------------------------- +// 4.4 - Output Driver Control Register +//-------------------------------------------------------------------- #define CFG_ODCR 0xe5 -/*-------------------------------------------------------------------- - * 4.8 - Error Handling Registers - *------------------------------------------------------------------*/ -#define CFG_ERRENR1 0x11 /* enable SDRAM refresh overflow error */ +//-------------------------------------------------------------------- +// 4.8 - Error Handling Registers +//-------------------------------CFG_SDMODE_BURSTLEN------------------------------------- +#define CFG_ERRENR1 0x11 // enable SDRAM refresh overflow error /* SDRAM 0-256 MB */ #define CFG_IBAT0L (CFG_SDRAM_BASE | BATL_PP_10 | BATL_MEMCOHERENCE) +//#define CFG_IBAT0L (CFG_SDRAM_BASE | BATL_PP_10 | BATL_CACHEINHIBIT) #define CFG_IBAT0U (CFG_SDRAM_BASE | BATU_BL_256M | BATU_VS | BATU_VP) /* stack in dcache */ #define CFG_IBAT1L (CFG_INIT_RAM_ADDR | BATL_PP_10 | BATL_MEMCOHERENCE) #define CFG_IBAT1U (CFG_INIT_RAM_ADDR | BATU_BL_128K | BATU_VS | BATU_VP) + +#define CFG_IBAT2L (CFG_SDRAM_BASE + 0x10000000 | BATL_PP_10 | BATL_MEMCOHERENCE) +#define CFG_IBAT2U (CFG_SDRAM_BASE + 0x10000000| BATU_BL_256M | BATU_VS | BATU_VP) + /* PCI memory */ -#define CFG_IBAT2L (0x80000000 | BATL_PP_10 | BATL_CACHEINHIBIT) -#define CFG_IBAT2U (0x80000000 | BATU_BL_256M | BATU_VS | BATU_VP) +//#define CFG_IBAT2L (0x80000000 | BATL_PP_10 | BATL_CACHEINHIBIT) +//#define CFG_IBAT2U (0x80000000 | BATU_BL_256M | BATU_VS | BATU_VP) -/* Flash, config addrs, etc. */ +/*Flash, config addrs, etc. */ #define CFG_IBAT3L (0xF0000000 | BATL_PP_10 | BATL_CACHEINHIBIT) #define CFG_IBAT3U (0xF0000000 | BATU_BL_256M | BATU_VS | BATU_VP) @@ -298,26 +367,30 @@ #define CFG_BOOTMAPSZ (8 << 20) /* Initial Memory map for Linux */ /*----------------------------------------------------------------------- - * FLASH organization (AMD AM29LV116D) - */ + * FLASH organization + *----------------------------------------------------------------------*/ #define CFG_FLASH_BASE 0xFF800000 +#define CFG_MAX_FLASH_BANKS 1 /* Max number of flash banks */ -#define CFG_MAX_FLASH_BANKS 1 /* Max number of flash banks */ -#define CFG_MAX_FLASH_SECT 35 /* Max number of sectors in one bank */ - -#define CFG_FLASH_ERASE_TOUT 120000 /* Timeout for Flash Erase (in ms) */ -#define CFG_FLASH_WRITE_TOUT 500 /* Timeout for Flash Write (in ms) */ - - /* Warning: environment is not EMBEDDED in the U-Boot code. - * It's stored in flash separately. - */ +/* NOTE: environment is not EMBEDDED in the ppcboot code. + It's stored in flash in its own separate sector. */ #define CFG_ENV_IS_IN_FLASH 1 +#if 1 /* AMD AM29LV033C */ +#define CFG_MAX_FLASH_SECT 64 /* Max number of sectors in one bank */ +#define CFG_ENV_ADDR 0xFFBF0000 /* flash sector SA63 */ +#define CFG_ENV_SECT_SIZE (64*1024) /* Size of the Environment Sector */ +#else /* AMD AM29LV116D */ +#define CFG_MAX_FLASH_SECT 35 /* Max number of sectors in one bank */ #define CFG_ENV_ADDR 0xFF9FA000 /* flash sector SA33 */ -#define CFG_ENV_SIZE 0x2000 /* Size of the Environment */ +#define CFG_ENV_SECT_SIZE (8*1024) /* Size of the Environment Sector */ +#endif /* #if */ + +#define CFG_ENV_SIZE CFG_ENV_SECT_SIZE /* Size of the Environment */ #define CFG_ENV_OFFSET 0 /* starting right at the beginning */ -#define CFG_ENV_SECT_SIZE 0x2000 /* Size of the Environment Sector */ +#define CFG_FLASH_ERASE_TOUT 120000 /* Timeout for Flash Erase (in ms) */ +#define CFG_FLASH_WRITE_TOUT 500 /* Timeout for Flash Write (in ms) */ #if CFG_MONITOR_BASE >= CFG_FLASH_BASE #undef CFG_RAMBOOT

2 2

[U-Boot-Users] mpc824x/start.S
by Matthew McClintock 28 May '03

28 May '03

I have a question for everyone on the list. I am booting u-boot on a custom mpc824x board (utx8245) and I have run into a minor annoyance. In start.S you have the following code in relocate_code: relocate_code: mr r1, r3 /* Set new stack pointer */ mr r9, r4 /* Save copy of Global Data pointer */ mr r10, r5 /* Save copy of Destination Address */ mr r3, r5 /* Destination Address */ #ifdef DEBUG lis r4, CFG_SDRAM_BASE@h /* Source Address */ ori r4, r4, CFG_SDRAM_BASE@l #else lis r4, CFG_MONITOR_BASE@h /* Source Address */ ori r4, r4, CFG_MONITOR_BASE@l #endif lis r5, CFG_MONITOR_LEN@h /* Length in Bytes */ ori r5, r5, CFG_MONITOR_LEN@l li r6, CFG_CACHELINE_SIZE /* Cache Line Size */ /* * Fix GOT pointer: * * New GOT-PTR = (old GOT-PTR - CFG_MONITOR_BASE) + Destination Address * * Offset: Now I am curious why when you are running in debug mode you choose to copy everything from CFG_SDRAM_BASE, while working normally you copy it from CFG_MONITOR_BASE. For us there is nothing to be copied at CFG_SDRAM_BASE and u-boot crashes right after it relocates the code and jumps to the copied point. We get around this obviously by doing the following: relocate_code: mr r1, r3 /* Set new stack pointer */ mr r9, r4 /* Save copy of Global Data pointer */ mr r10, r5 /* Save copy of Destination Address */ mr r3, r5 /* Destination Address */ #ifdef DEBUG lis r4, CFG_MONITOR_BASE@h /* Source Address */ ori r4, r4, CFG_MONITOR_BASE@l #else lis r4, CFG_MONITOR_BASE@h /* Source Address */ ori r4, r4, CFG_MONITOR_BASE@l #endif lis r5, CFG_MONITOR_LEN@h /* Length in Bytes */ ori r5, r5, CFG_MONITOR_LEN@l li r6, CFG_CACHELINE_SIZE /* Cache Line Size */ /* * Fix GOT pointer: * * New GOT-PTR = (old GOT-PTR - CFG_MONITOR_BASE) + Destination Address * * Offset: This is a hack, and it cannot be merged back into u-boot so I was wondering if there was a more eloquent way to do this, something else I am missing that will make my program work while in debug mode with an unmodified start.S. Thanks for your time, Matthew

2 1

[U-Boot-Users] New x86 board booted...now the hard part
by Marc Singer 27 May '03

27 May '03

Yipee! It boots. I have a few questions. 1) Daniel, do you think that the 'fs' overrides in mem_init are necessary when ds == fs? 2) How would you expect to override mem_init on another x86 board? It seems to me that we'd be better off with a BSP entry point for RAM initialization that calls the appropriate library function(s). 3) We ought to be able to share serial driver code between x86 and the risc processors as long as we abstract port accesses the way that the Linux kernel does. Has this been discussed?

3 8

RE: [U-Boot-Users] strataflash.c
by Brad Kemp 27 May '03

27 May '03

I agree, the strataflash driver as it stands now will not work. Brad > -----Original Message----- > From: Tom Guilliams [mailto:tguilliams@sbs.com] > Sent: Tuesday, May 13, 2003 2:52 PM > To: 'u-boot-users(a)lists.sourceforge.net' > Cc: 'Frank Smith' > Subject: RE: [U-Boot-Users] strataflash.c > > > In a x16 device in x8 mode, the portwidth should be 1. However, CFI > detection in strataflash.c will not work in this mode. It > will look for the > CFI QRY at 0x10, 0x11, 0x12 offsets when they're actually at > double that > offset (portwidth = 2). > > I agree that the portwidth is not be used correctly in the > case of a x16 > device in x8 mode. For the meantime, the hack I've made will > sustain me > until I or someone else can add support for this chipset mode > to the driver. > > Tom > > -----Original Message----- > From: Frank Smith [mailto:smith@amirix.com] > Sent: Sunday, May 11, 2003 4:51 PM > To: Tom Guilliams; u-boot-users(a)lists.sourceforge.net > Cc: Frank Smith > Subject: Re: [U-Boot-Users] strataflash.c > > > Hi, > > The more I look into strataflash.c, the more I'm starting to > think that it > doesn't support x16 devices in x8 mode. > > The problem I see is that the 'portwidth' value is used to > drive two things > -- offset multiplier, and side of data reads/writes to the > flash device. > > On a pure x16 device, the offset multiplier is 2 and the size > of the data > read/writes is 2. So portwidth is 2. > > On an x16 device in x8 mode, however, the offset multiplier > is 2, but the > size of data read/writes is 1. What should portwidth be...? > > I think the offset multiplier and size of data read/writes > should be driven > by *different* values. Or am I overlooking something obvious? > > > Thanks, > Frank. > > ----- Original Message ----- > From: "Tom Guilliams" <tguilliams(a)sbs.com> > To: "'Frank Smith'" <smith(a)amirix.com>; > <u-boot-users(a)lists.sourceforge.net> > Sent: Friday, May 09, 2003 7:14 PM > Subject: RE: [U-Boot-Users] strataflash.c > > > > Frank, > > > > I can tell you I've had some problems with a x16 in x8 mode in > > strataflash.c. Basically, the flash_detect_cfi() routine > detects my > > E28F128J3A chip as portwidth 2 (x16) and chipwidth 1 (x8). All the > > CFI > info > > is read correctly. However, any write accesses to chip > (programming > > or > > erasing) fail upon the calculated offset (it's incorrectly > doubled because > > of portwidth being 2). > > > > I had to manually force the portwidth to 1 (x8) after the > > flash_get_size() routine to make everything behave for any flash > > operations. > > > > I don't think the "detect" logic is correct in terms of > port and chip > width > > for "some" devices. However, the author - Brad Kemp - has > said he's > > had success on numerous other flash width devices. > > > > Your problem sounds exactly like mine. For a hack fix, set > > > > info->portwidth = 1; > > > > for the last thing flash_get_size() does before returning the size. > > > > Tom > > > > -----Original Message----- > > From: Frank Smith [mailto:smith@amirix.com] > > Sent: Friday, May 09, 2003 1:00 PM > > To: u-boot-users(a)lists.sourceforge.net > > Subject: [U-Boot-Users] strataflash.c > > > > > > > > Hello, > > > > I have a board with a couple of Intel RC28F320J3A > Strataflash devices. > One > > device is wired to x16 mode, the other to x8 mode. > > > > I'm trying to use the strataflash.c driver with these flash chips. > > The driver detects the flash that's in x16 mode, but not > the one in x8 > > mode. So I'm digging through the code to try to figure out > what's up. > > I've been successful in avoiding dealing with flash > programming code > > up until now in my life..... > > > > If anyone knows anything about whether strataflash.c was > designed to > > work with x16 devices in x8 mode, I'd love to hear from > you! From what > > I've > seen > > so far, I'm tending to think that it doesn't. > > > > > > Thanks, > > Frank. > > > > > > ------------------------------------------------------- > > Enterprise Linux Forum Conference & Expo, June 4-6, 2003, > Santa Clara > > The only event dedicated to issues related to Linux enterprise > > solutions www.enterpriselinuxforum.com > > > > _______________________________________________ > > U-Boot-Users mailing list > > U-Boot-Users(a)lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/u-boot-users > > > > > > ------------------------------------------------------- > > Enterprise Linux Forum Conference & Expo, June 4-6, 2003, > Santa Clara > > The only event dedicated to issues related to Linux enterprise > > solutions www.enterpriselinuxforum.com > > > > _______________________________________________ > > U-Boot-Users mailing list > > U-Boot-Users(a)lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/u-boot-users > > > > > ------------------------------------------------------- > Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara > The only event dedicated to issues related to Linux > enterprise solutions > www.enterpriselinuxforum.com > > _______________________________________________ > U-Boot-Users mailing list > U-Boot-Users(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/u-boot-users >

1 0

[U-Boot-Users] linux doesn't boot when CS for initial cache disabled
by Thomas Schäfer 27 May '03

27 May '03

Hi all, I'm testing with an IBM Walnut board (PPC405GP) with u-boot 0.3.0 and 2.4.17 kernel from Montavista. After booting u-boot and loading the kernel via tftp, I submit the following commands on the console: => setdcr 12 0012: 00000004 ? 7 0012: 00000007 ? . => setdcr 13 0013: 400da000 ? 0 0013: 00000000 ? . This disables CS7, which is used for the temporary stack in my configuration. After that, I can still load a linux kernel via tftp, but it hangs in the early bootup sequence when turning the MMU on. I found that the data cache for the temporary stack has to be flushed and disabled before the CS for the temporary stack is disabled. I changed the u-boot code at this point and everything worked fine. Here the changes in the code are summarized: /board/walnut405/walnut405.c: - The function board_pre_init was divided and a new function board_pre_init_r was created, which contains the EBC programming /include/common.h: - The prototype for board_pre_init_r was added /cpu/ppc4xx/cpu_init.c - In the cpu_init_r function, data cache is flushed and disabled first. After that the CS for the temporary stack is disabled and board_pre_init is called to program the EBC. This means that the EBC is programmed later in the boot process than before, but EBC programming seems not to be necessary that early (with the exception of the CS for the NVRAM, where the programming was left in board_pre_init). - In the cpu_init_f function, the EBC programming code was moved into cpu_init_r. I had to do those changes, because all available CS lines are used on one of our custom boards. Now I have the possibility to use a CS for the temporary stack in early boot stage and for hardware devices after relocation. If the changes are of some use for the project, I can provide a patch. Best regards, Thomas Schäfer ____________________________________ GIGA STREAM - UMTS Technologies GmbH Konrad-Zuse-Str. 7 66115 Saarbrücken Tel.: + 49 (0)681 / 95916 - 203 Fax: + 49 (0)681 / 95916 - 100 E-mail: tschaefer(a)giga-stream.de

2 1

RE: [U-Boot-Users] Loads function and flow control.
by Christophe.LINDHEIMER＠fr.thalesgroup.com 27 May '03

27 May '03

Just great ! Thanks. -----Message d'origine----- De: Wolfgang Denk [mailto:wd@denx.de] Date: mardi 27 mai 2003 13:10 À: Christophe.LINDHEIMER(a)fr.thalesgroup.com Cc: u-boot-users(a)lists.sourceforge.net Objet: Re: [U-Boot-Users] Loads function and flow control. In message <D96E2AFA0DF3D211B139009027454948034CBD9C(a)helios.gnv.tcc.thomson-csf.com> you wrote: > > > All this is documented in detail in http://www.denx.de/re/DPLG.html > > Is there an easy way to read this doc when > - there is only on PC connected on the web for 40 persons in the > company. > - I can't install any soft on this PC to suck the whole doc. You can download it in different formats as a single file: * http://www.denx.de/doc/TQM8xxL/dplg.html = HTML * http://www.denx.de/doc/TQM8xxL/dplg.txt = plain ASCII text * http://www.denx.de/doc/TQM8xxL/dplg.ps = compressed PostScript European A4 format * http://www.denx.de/doc/TQM8xxL/dplg.pdf = PDF European A4 format * http://www.denx.de/doc/TQM8xxL/dplg.sgml = SGML source 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 Condense soup, not books!

1 0

[U-Boot-Users] U-BOOT+GDB+BDI
by Karoliya, Abhishek 27 May '03

27 May '03

Hi , I have working U-boot for my 8245 board ,the porting of which required the BDI. Now with this working image , I am trying to use GDB + BDI for source level debugging to add other components in U-boot. The problem is when i start GDB {ppc_82XX-gdb u-boot -s u-boot.map} and I single step in start.S file , it works fine until the sync instruction under boot_warm label but as soon i single step it , the gdb goes blank{as in it returns to new line without printing } although the u-boot comes up to prompt as seen at serial console. where I am going wrong ...... Thanks Abhi

1 0

[U-Boot-Users] Complie time errors ..building u-boot for smdk2400(arm920t) board
by Gupta, Kshitij 27 May '03

27 May '03

hi , I am trying to compile u-boot for smdk2400(arm920t) board. I downloaded u-boot from http://sourceforge.net/projects/u-boot. Downloaded the crosscompiler from ftp://ftp.arm.linux.org.uk/pub/linux/arm/toolchain/. After unzipping these things whe I try to compile u-boot , I get the following errors ----------- as: unrecognized option `-marmv4' In file included from crc32.c:12: /home/a0875451/mwd/u-boot/u-boot-0.3.0/include/common.h:39: asm/ptrace.h: No such file or directory /home/a0875451/mwd/u-boot/u-boot-0.3.0/include/common.h:40: stdarg.h: No such file or directory In file included from /home/a0875451/mwd/u-boot/u-boot-0.3.0/include/common.h:62, from crc32.c:12: /home/a0875451/mwd/u-boot/u-boot-0.3.0/include/flash.h:47: output pipe has been closed cpp0: output pipe has been closed make[1]: *** [crc32.o] Error 1 make[1]: Leaving directory `/home/a0875451/mwd/u-boot/u-boot-0.3.0/lib_generic' make: *** [subdirs] Error 1 ---------------- I tried to look for ptrace.h file. Found it in /u-boot-0.3.0/include/asm-arm/proc-armv. But I was not able to find the stdargs.h file. Can someone please guide me if I am downloading the u-boot from the correct place and how can I resolve these errors. regards -kshitij -----Original Message----- From: Wolfgang Denk [mailto:wd@denx.de] Sent: Tuesday, May 27, 2003 1:54 PM To: Christophe.LINDHEIMER(a)fr.thalesgroup.com Cc: u-boot-users(a)lists.sourceforge.net Subject: Re: [U-Boot-Users] Loads function and flow control. In message <D96E2AFA0DF3D211B139009027454948034CBD9B(a)helios.gnv.tcc.thomson-csf.com> you wrote: > > > Even better avoid serial downloads completely and use TFTP. > > Well, it should be with a lot of pleasure but hardware people have > "forgotten" ethernet link on my board :(( Urrrgh... Sincere condolences. 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 Real computer scientists despise the idea of actual hardware. Hard- ware has limitations, software doesn't. It's a real shame that Turing machines are so poor at I/O. ------------------------------------------------------- This SF.net email is sponsored by: ObjectStore. If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Check out ObjectStore. Now part of Progress Software. http://www.objectstore.net/sourceforge _______________________________________________ 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] Loads function and flow control.
by Christophe.LINDHEIMER＠fr.thalesgroup.com 27 May '03

27 May '03

> > All this is documented in detail in http://www.denx.de/re/DPLG.html > Is there an easy way to read this doc when - there is only on PC connected on the web for 40 persons in the company. - I can't install any soft on this PC to suck the whole doc. however I have just printed chapter 3 and it looks fine.. Thanks. Chris

2 1

RE: [U-Boot-Users] Loads function and flow control.
by Christophe.LINDHEIMER＠fr.thalesgroup.com 27 May '03

27 May '03

Hi. I have just installed the great rpm uucp to use cu. so I make cu -s 9600 -l ttyS1 --nostop. Unfortunately, it seems that what I type isn't sent to my board !! It works fine with minicom. It seems that it is because of the flow control. In minicom I choose no software and no hardware flow control to make it work. How can I do the same with cu ? My serial cable is only RX TX & GND. Thanks Chris

2 1

[U-Boot-Users] Patch to drivers/pci.c
by Donald White 27 May '03

27 May '03

Following is a patch to drivers/pci.c. It fixes the calculation of the base address in pci_hose_config_device(). diff -urN u-boot-0.3.0/drivers/pci.c u-boot-0.3.0-zpc1900/drivers/pci.c --- u-boot-0.3.0/drivers/pci.c Thu Feb 27 17:19:49 2003 +++ u-boot-0.3.0-zpc1900/drivers/pci.c Tue May 20 20:51:35 2003 @@ -329,9 +329,12 @@ if (bar_response & PCI_BASE_ADDRESS_SPACE) { bar_size = ~(bar_response & PCI_BASE_ADDRESS_IO_MASK) + 1; - bar_value = io; + /* round up region base address to a multiple of size */ io = ((io - 1) | (bar_size - 1)) + 1; + bar_value = io; + /* compute new region base address */ + io = io + bar_size; } else { @@ -340,9 +343,12 @@ found_mem64 = 1; bar_size = ~(bar_response & PCI_BASE_ADDRESS_MEM_MASK) + 1; - bar_value = mem; + /* round up region base address to multiple of size */ mem = ((mem - 1) | (bar_size - 1)) + 1; + bar_value = mem; + /* compute new region base address */ + mem = mem + bar_size; } /* Write it out and update our limit */

2 1

RE: [U-Boot-Users] Loads function and flow control.
by Christophe.LINDHEIMER＠fr.thalesgroup.com 27 May '03

27 May '03

> > Well, I use a serial line at 9600 Bauds. > > :-( > > > I use minicom to send commands to UBoot. > > > > Once the loads is done I make a > > cat hello_world.srec > /dev/ttyS1 > > in order not to use minicom to keep Wolfgang in good mood > for the whole week > > :-)) > > Have you ever seen me in bad mood? This is a _very_ uncommon state > for me. > > > The first data are corrects but UBoot aborts the download > after a few > > lines... > > If you _must_ use s-records, use "cu". > > Better avoid s-reocrds and use kermit binary protocol ("loadb"). > > Even better avoid serial downloads completely and use TFTP. > Well, it should be with a lot of pleasure but hardware people have "forgotten" ethernet link on my board :(( Chris

2 1

[U-Boot-Users] Shared serial driver
by Marc Singer 27 May '03

27 May '03

I now remember why there is an x86 specific serial driver. Unlike every other chip, the x86 has a separately mapped I/O port address space. Sharing the driver will require some inline functions or macros to bridge the gap. If continue to take from the Linux kernel model, there are CPU specific macros to read and write in the IO space. I also seem to recall that the spacing of IO addresses is different on each CPU. Some are forced to be 32 bit aligned while others may be word aligned. There is a little bit of work to fit all of the pieces together. Fortunately, the 16550 driver is simple enough to be a reliable test bed. Are you good with this path? Cheers.

2 1

[U-Boot-Users] Doubt on Kernel Linking
by Rupesh S 27 May '03

27 May '03

Hi, I work with MPC823FADS board. I'm using u-boot as the bootloader in it. The RAM memroy map as seen with the "bdinfo" command in u-boot says.. 0x00000000 to 0x00800000. I'm trying to boot linux kernel ( linux-2.4.4-2002-10-06 from DENX) on my board. By default , the kernel is build at 0xC0000000. (This memory is not mapped by u-boot). Do I have to change the kernel linking to a address that is within, 0x00000000 and 0x00800000 ? Rupesh

3 10

[U-Boot-Users] Sharing the serial driver
by Marc Singer 26 May '03

26 May '03

There appears to be a serial driver in most every BSP. Are you willing to merge a driver than can be shared among CPUs and boards?

2 1

[U-Boot-Users] Loads function and flow control.
by Christophe.LINDHEIMER＠fr.thalesgroup.com 26 May '03

26 May '03

Hi. I am just starting to work with loads function. Is there any mechanism for software flow control ( XON, XOFF ) ? I have seen some define for loadb bu nothing for loads... It seems that loads works fine when I download small files but get lost with big ones. So I fear a flow control problem. What is the problem with minicom for loads ? I think that loads just expect to receive ascii data. Is it wrong to send srec file using ALT S in minicom ( and choosing ascii data ) ? Chris

5 10

RE: [U-Boot-Users] Loads function and flow control.
by Christophe.LINDHEIMER＠fr.thalesgroup.com 26 May '03

26 May '03

Well, I use a serial line at 9600 Bauds. I use minicom to send commands to UBoot. Once the loads is done I make a cat hello_world.srec > /dev/ttyS1 in order not to use minicom to keep Wolfgang in good mood for the whole week :-)) The first data are corrects but UBoot aborts the download after a few lines... => mw 0x4000 0 200 => loads ## Ready for S-Record download ... S013000068656C6C6F5F776F726C642E7372656376 S214040000000181749421FFE07C0802A6BF61000C05 S21404001090010024480000057FC802A6801EFFE861 S2140400207FC0F2147C7B1B78807E80007C9F2378C4 S214040030480000B1807E80047F64DB78480000A519 S2140400403B8000007C1CD8004181003080BF00004B S2140400503BFF00042C0500004082000880BE800898 S214040060807E800C7F84E378480000793B9C000106 ## S-Record download abortedE80104800006534 => 4204E8000208B Unknown command '4204E8000208B' - try 'help' => => 440000024E800020380000024400000273 Unknown command '440000024E800020380000024400000273' - try 'help' => => 420380000055A Unknown command '420380000055A' - try 'help' => => 080002038000007440000024E80002085 Unknown command '080002038000007440000024E80002085' - try 'help' => => 000A440000020A Unknown command '000A440000020A' - try 'help' => => 60000008B Unknown command '60000008B' - try 'help' => => 21545B25645D203D20222573220A00000000ED Unknown command '21545B25645D203D20222573220A00000000ED' - try 'help' => => 72E2E2081 Unknown command '72E2E2081' - try 'help' => => 4144000501640005015015 Unknown command '4144000501640005015015' - try 'help' => => md 0x40000 00040000: 00018174 9421ffe0 7c0802a6 bf61000c ...t.!..|....a.. 00040010: 90010024 48000005 7fc802a6 801effe8 ...$H........... 00040020: 7fc0f214 7c7b1b78 807e8000 7c9f2378 ....|{.x.~..|.#x 00040030: 480000b1 807e8004 7f64db78 480000a5 H....~...d.xH... 00040040: 3b800000 7c1cd800 41810030 80bf0000 ;...|...A..0.... 00040050: 3bff0004 2c050000 40820008 80be8008 ;...,...@....... 00040060: 807e800c 7f84e378 48000079 3b9c0001 .~.....xH..y;... 00040070: 00000000 00000000 00000000 00000000 ................ 00040080: 00000000 00000000 00000000 00000000 ................ 00040090: 00000000 00000000 00000000 00000000 ................ 000400a0: 00000000 00000000 00000000 00000000 ................ 000400b0: 00000000 00000000 00000000 00000000 ................ 000400c0: 00000000 00000000 00000000 00000000 ................ 000400d0: 00000000 00000000 00000000 00000000 ................ 000400e0: 00000000 00000000 00000000 00000000 ................ 000400f0: 00000000 00000000 00000000 00000000 ................

2 1

[U-Boot-Users] U-boot +BDI2000 code downloading
by Karoliya, Abhishek 24 May '03

24 May '03

Hi , I am trying to port u-Boot to a custom 8245 board using BDI2000 in the progress . I tried using the facility of BDI to download code {U-boot.bin} using the HOST section of the configuration file {sp8240.cfg}. For this purpose do I have to make changes to address where u-boot is linked or what offset should I download. Just wondering how would BDI can place the code in memory when the RAM interface has been configured {timings etc}. Also if I burn the Flash using BDI for u-boot.bin should I have to give address 0xfff00000 or 0xfff0 0100. thanks Abhi

1 0

[U-Boot-Users] PCI support on the PrPMC800
by Mark.Lightfoot＠sita.aero 24 May '03

24 May '03

Hello, My port of U-Boot the to Motorola PrPMC800 continues. My next task it to add PCI support. At this point I don't have a clue what to do! I've got the function stub, pci_init_board(), being executed but its an empty function and does nothing. What should it do? The board uses a Motorola Harrier ASIC to bridge the PowerPC bus to PCI so obviously I've have to configure that. But is that it. Does the U-Boot code take over from there and start scanning and mapping/configuring PCI devices from there? Another problem is my lack of knowledge on the finer point of how PCI works. Any one recommend a good source of such information? Regards, Mark ><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< Mark Lightfoot - Software Designer - SITA 777 Walker's Line, Burlington, Ontario, Canada, L7N 2G1 905-681-5575 mark.lightfoot(a)sita.aero ><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

1 0

[U-Boot-Users] effort required to port u-boot
by Gupta, Kshitij 24 May '03

24 May '03

Hi, Does anyone have an idea of the effort required to port the full uboot to a new arm based target?? Please excuse me for the nature of the question but if anyone has done it already he can suggest abt how much time he took to port the whole u-boot on a new target (just a very rough estimate), assuming that the developer has a very good knowledge of the target but at a comfort level [medium] on linux.. Any comments will be really helpful Regards, kshitij

4 3

RE: [U-Boot-Users] UBoot hangs in serial_putc on mpc8xx
by Christophe.LINDHEIMER＠fr.thalesgroup.com 23 May '03

23 May '03

Hum hum... I have the feeling that you next mail will tell me that I should have read more deeply the Readme ... Sorry... & thanks for help !! Chris -----Message d'origine----- De: Wolfgang Denk [mailto:wd@denx.de] Date: vendredi 23 mai 2003 15:38 À: Christophe.LINDHEIMER(a)fr.thalesgroup.com Cc: nyet(a)mrv.com; u-boot-users(a)lists.sourceforge.net Objet: Re: [U-Boot-Users] UBoot hangs in serial_putc on mpc8xx In message <D96E2AFA0DF3D211B13900902745494803736286(a)helios.gnv.tcc.thomson-csf.com> you wrote: > > In fact it seems that the get_clocks return a freq of 33.6 Mhz whereas = > it > should be 38.4 Mhz... Do you have a clock connected to EXTAL, and which clock frequency is this? 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 The easiest way to figure the cost of living is to take your income and add ten percent.

2 1

RE: [U-Boot-Users] UBoot hangs in serial_putc on mpc8xx
by Christophe.LINDHEIMER＠fr.thalesgroup.com 23 May '03

23 May '03

>> >> In fact it seems that the get_clocks return a freq of 33.6 Mhz whereas = >> it >> should be 38.4 Mhz... > >Do you have a clock connected to EXTAL, and which clock frequency is this? It seems that there is a lovely pull up on EXTAL... Chris

2 1

RE: [U-Boot-Users] UBoot hangs in serial_putc on mpc8xx
by Christophe.LINDHEIMER＠fr.thalesgroup.com 23 May '03

23 May '03

Hi. In fact it seems that the get_clocks return a freq of 33.6 Mhz whereas it should be 38.4 Mhz... So a #define CONFIG_8xx_GCLK_FREQ in the file config for my board works fine. I have now U-boot writing on the console. Thanks for help. Chris -----Message d'origine----- De: nyet(a)mrv.com [mailto:nyet@mrv.com] Date: jeudi 22 mai 2003 21:58 À: Wolfgang Denk Cc: Christophe.LINDHEIMER(a)fr.thalesgroup.com; u-boot-users(a)lists.sourceforge.net Objet: Re: [U-Boot-Users] UBoot hangs in serial_putc on mpc8xx The 8xx BRG code is has an interesting side effect if the cpu clock rate is not properly detected... the divisor will overflow the allowed bitwidth and an invalid value will get put brgc1 Hardcode CONFIG_8xx_GCLK_FREQ and/or brgc1 in speed.c and serial.c I am working on putting together a fairly extensive 8xx patch to address this and many other problems.

2 1

[U-Boot-Users] CFG_MONITOR_BASE, CFG_FLASH_BASE, TEXT_BASE
by Bogdan Woldert-Jokisz 23 May '03

23 May '03

hi what are the macros CFG_MONITOR_BASE, CFG_FLASH_BASE and TEXT_BASE ? I think, CFG_FLASH_BASE is the lowest address of the flash. But what are the other macros? My problem: My flash memory (8MB) starts at 0xff800000. But the bootloader should start at 0xfff80000. Is it possible? The bootloader works if I define CFG_FLASH_BASE to 0xfff80000, but I need the real start address of the flash memory in the board-info-structure. Thanks Bogdan

2 1

[U-Boot-Users] [PATCH] change xscale to pxa
by Kyle Harris 23 May '03

23 May '03

In preparation for an ixp port, this patch renames cpu/xscale and arch-xscale to cpu/pxa and arch-pxa. It is applied against CVS timestamp 030520. MAKEALL completes for LIST_pxa. (Is there a better way for simply renaming directories?) Kyle.

2 1

RE: [U-Boot-Users] Doubt on Kernel Linking
by Flavio Pereira 23 May '03

23 May '03

Hi Rupesh >I'm trying to boot linux kernel ( linux-2.4.4-2002-10-06 from DENX) on my board. >By default , the kernel is build at 0xC0000000. (This memory is not mapped by u-boot). >Do I have to change the kernel linking to a address that is within, 0x00000000 and 0x00800000 ? The address 0xC0000000 is the virtual memory address in which the kernel runs, when the kernel decompresses you should see that it decompressed into the physical address 0x0, which is mapped by U-Boot. Therefore there is no problem in the kernel linking at 0xC0000000. Regards Flavio Pereira

1 0

[U-Boot-Users] Re: MIP405-3 Patch
by Wolfgang Denk 23 May '03

23 May '03

Dear Denis, in message <200305190957.h4J9vBQW023721(a)pip5.mpl.ch> you wrote: > > attached is a patch against the current CVS which will add support for the > MIP405-3 (405GPR) Board. Thanks, added. 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 "Whoever undertakes to set himself up as a judge of Truth and Know- ledge is shipwrecked by the laughter of the gods." - Albert Einstein

1 0

[U-Boot-Users] [patch] MPC8266 March-C memory test
by Rune Torgersen 23 May '03

23 May '03

Patch to do full March-C- memory test on the MPC8266ADS board. Later on I will probably include it as a command, right now it runs as test_dram() which is called first thing after SDRAM is initializes, and before anything uses the SDRAM. Note: Fast version uses floating point assembly and is therefore PPC specific. Generic version takes more than twice the amount of time to complete. (Fast version: ~50 sec on 256MB RAM, slow version ~1:50 on 256MB RAM) ADS Rune Torgersen Software Developer Innovative Systems 1000 Innovative Drive Mitchell, SD 57301 Phone: 605-995-6120 Fax: 605-995-0084 email: runet(a)innovsys.com www.innovsys.com

3 4

RE: [U-Boot-Users] UBoot hangs in serial_putc on mpc8xx
by Christophe.LINDHEIMER＠fr.thalesgroup.com 23 May '03

23 May '03

> > it is a custom board with a mpc8xx. > > Then the answer to your question is simple: you made some errors in > your port of U-Boot to your hardware. I know, this is just an anwer > to your question, not a solution to your problem. > > > I think that most of the config is board independant. ( > Prog of the BRG, > > Prog of the CPM ... ) > > You are wrong. A LOT of the configuration parameters are hardware > specific. > > > U-Boot finds 9600 for the baudrate in the env. > > So I wonder where board specific items can make it hang. > > Basicly anything. Bad clock configuration for example. > You right. It seems that with new values for clock registers it works much better... So it doesn't hang anymore and I reach the getc(). I still don't have anything on my terminal console but the solution can't be far ! Chris

1 0

[U-Boot-Users] Changed to get CVS head to build sc520_cdp
by Marc Singer 23 May '03

23 May '03

Both 0.3.0 and the latest head revision refused to build until I made this patch. Am I misunderstanding something? diff -ru u-boot-0.3.0/include/asm-i386/u-boot.h ../coastal/uboot/u-boot-0.3.0/include/asm-i386/u-boot.h --- u-boot-0.3.0/include/asm-i386/u-boot.h Sun Nov 17 15:11:13 2002 +++ ../coastal/uboot/u-boot-0.3.0/include/asm-i386/u-boot.h Tue May 6 00:44:33 2003 @@ -44,6 +44,8 @@ unsigned long bi_intfreq; /* Internal Freq, in MHz */ unsigned long bi_busfreq; /* Bus Freq, in MHz */ unsigned long bi_baudrate; /* Console Baudrate */ + /* *** added to get the code to compile for x86 */ + unsigned long bi_boot_params; /* where this board expects params */ struct environment_s *bi_env; struct /* RAM configuration */ { My method was simple. > make sc520_cdp_config > make ######################################## On another track, I suspect that there may be a typographically generated bug in cpu/i386/start16.S. The code reads like this. /* Turn of cache (this might require a 486-class CPU) */ movl %cr0, %eax orl $060000000,%eax movl %eax, %cr0 wbinvd I believe that the correct immediate value is $0x60000000. The given octal value is 0x00c00000 hexadecimal. According to the Intel documentation I have on hand, these bits are presently reserved in %cr0.

2 1

[U-Boot-Users] configs/FADS860T.h
by Nye Liu 23 May '03

23 May '03

None of these values from include/configs/FADS860T.h are used in boards/fads/fads.c... Is somebody else working in fads.c other than me currently? I am about to rewrite large portions of it. --------------- snip --------------- /* periodic timer for refresh */ #define CFG_MAMR_PTA 97 /* start with divider for 100 MHz */ /* refresh rate 15.6 us (= 64 ms / 4K = 62.4 / quad bursts) for <= 128 MBit */ #define CFG_MPTPR_2BK_4K MPTPR_PTP_DIV16 /* setting for 2 banks */ #define CFG_MPTPR_1BK_4K MPTPR_PTP_DIV32 /* setting for 1 bank */ /* refresh rate 7.8 us (= 64 ms / 8K = 31.2 / quad bursts) for 256 MBit */ #define CFG_MPTPR_2BK_8K MPTPR_PTP_DIV8 /* setting for 2 banks */ #define CFG_MPTPR_1BK_8K MPTPR_PTP_DIV16 /* setting for 1 bank */ /* * MAMR settings for SDRAM */ /* 8 column SDRAM */ #define CFG_MAMR_8COL ((CFG_MAMR_PTA << MAMR_PTA_SHIFT) | MAMR_PTAE | \ MAMR_AMA_TYPE_0 | MAMR_DSA_1_CYCL | MAMR_G0CLA_A11 | \ MAMR_RLFA_1X | MAMR_WLFA_1X | MAMR_TLFA_4X) /* 9 column SDRAM */ #define CFG_MAMR_9COL ((CFG_MAMR_PTA << MAMR_PTA_SHIFT) | MAMR_PTAE | \ MAMR_AMA_TYPE_1 | MAMR_DSA_1_CYCL | MAMR_G0CLA_A10 | \ MAMR_RLFA_1X | MAMR_WLFA_1X | MAMR_TLFA_4X) #define CFG_MAMR 0x13a01114 -- Nye Liu nliu(a)mrv.com (818) 772-6235x248 "Who would be stupid enough to quote a fictitious character?" -- Don Quixote

2 2

[U-Boot-Users] bringing up a new x86 board
by Marc Singer 23 May '03

23 May '03

Daniel, I found one patch you've made (april 30'th) to u-boot-3.0 since it was released in early April. Are there any others? Also, when I attempted to apply the patch I found in the archive, I discovered it was truncated. Would you be kind enough to send me a copy?

1 0

RE: [U-Boot-Users] UBoot hangs in serial_putc on mpc8xx
by Christophe.LINDHEIMER＠fr.thalesgroup.com 22 May '03

22 May '03

>> >> I have just flashed U-Boot. > >Which board configuration? it is a custom board with a mpc8xx. I think that most of the config is board independant. ( Prog of the BRG, Prog of the CPM ... ) U-Boot finds 9600 for the baudrate in the env. So I wonder where board specific items can make it hang. >> It starts but it seems it hangs in serial_putc ( in the while at the end of >> the function ). >> Any idea about what to look ? > >With that little information you provide? Sorry... Well, I thought ( and hoped ) that I made a standard mistake somewhere ... Chris

3 2

[U-Boot-Users] PCI patch for MPC8266
by Rune Torgersen 22 May '03

22 May '03

Patch for getting PCI to work on a MPC8266ADS board. Also incorporates change to /cpu/mpc8260/pci.c to enable overrides of PCI memory parameters Rune Torgersen Software Developer Innovative Systems 1000 Innovative Drive Mitchell, SD 57301 Phone: 605-995-6120 Fax: 605-995-0084 email: runet(a)innovsys.com www.innovsys.com

2 1

[U-Boot-Users] UBoot hangs in serial_putc on mpc8xx
by Christophe.LINDHEIMER＠fr.thalesgroup.com 22 May '03

22 May '03

Hi. I have just flashed U-Boot. It starts but it seems it hangs in serial_putc ( in the while at the end of the function ). Any idea about what to look ? Thanks Chris

2 1

[U-Boot-Users] ECC DIMM's with walnut board
by Thomas Schäfer 22 May '03

22 May '03

Hi all, I tried to boot a walnut board with a 256 ECC DIMM using u-boot 0.3.0, but didn't succeed. When examining the code in the function spd_sdram in cpu/ppc4xx/spd_sdram, I found that the ECC configuration code is probably wrong. I suppose, that the following lines /* now check for ECC ability of module. We only support ECC * on 32 bit wide devices with 8 bit ECC. */ if ( (read_spd(11)==2) && ((read_spd(6)==40) || (read_spd(14)==8)) ){ sdram0_ecccfg=0xf<<SDRAM0_ECCCFG_SHIFT; ecc_on = 1; should be replaced with /* now check for ECC ability of module. We only support ECC * on 32 bit wide devices with 8 bit ECC. */ ==> if ( (read_spd(11)==2) && ((read_spd(6)==40) && read_spd(14)==8)) ){ <== sdram0_ecccfg=0xf<<SDRAM0_ECCCFG_SHIFT; ecc_on = 1; The reason is, that the if statement in the first code is also true for 72 bit ECC devices. So ECC is enabled for such a device which fails in the following. The changed code works for me with several DIMM types (32MB without ECC, 256 MB with ECC and without ECC), but I'm not an expert with all types of SDRAM and so I'm not sure if I fully understood the code in that place. Any ideas, comments? Best regards Thomas Schäfer ____________________________________ GIGA STREAM - UMTS Technologies GmbH Konrad-Zuse-Str. 7 66115 Saarbrücken Tel.: + 49 (0)681 / 95916 - 203 Fax: + 49 (0)681 / 95916 - 100 E-mail: tschaefer(a)giga-stream.de

3 2

[U-Boot-Users] I386 U-boot update
by Daniel Engström 22 May '03

22 May '03

Hello I have attached a number of patches wich updates Uboot to my current version for i386. Some common files are touched, mostly small changes except for the IDE driver which I made some more changes for code readability and 386 support, I hope that it still works for the PPC case. I will be out of the office until May 14. so any comments will not be answred until then. /Daniel

2 2

Re: [U-Boot-Users] Please explain this code in drivers/pci.c
by Donald White 21 May '03

21 May '03

Udi, I am convinced now it is incorrect. A minimal fix is to make the code look like this: /* Check the BAR type and set our address mask */ if (bar_response & PCI_BASE_ADDRESS_SPACE) { bar_size = ~(bar_response & PCI_BASE_ADDRESS_IO_MASK) + 1; /* round up region base address to a multiple of size */ io = ((io - 1) | (bar_size - 1)) + 1; bar_value = io; /* compute new base address for region */ io = io + bar_size; } else { if ( (bar_response & PCI_BASE_ADDRESS_MEM_TYPE_MASK) == PCI_BASE_ADDRESS_MEM_TYPE_64) found_mem64 = 1; bar_size = ~(bar_response & PCI_BASE_ADDRESS_MEM_MASK) + 1; /* round up region base address to multiple of size */ mem = ((mem - 1) | (bar_size - 1)) + 1; bar_value = mem; /* compute new region base address */ mem = mem + bar_size; } The ORing just rounds up the current base for the region to be a multiple of the size. The ORing was in the wrong place and there was no increment of the region base to beyond the allocated area. It worked with cards with single BARs and suitable region bases. This is not optimal, but it is useable for simple cases. Thanks for the comments, Don Udi Finkelstein wrote: > I've looked at the code you posted, and it looks indeed incorrect. (I > didn't look into the entire file in u-boot, so take this with a grain of > salt). > However, and optimal PCI alolcator must sort the BAR size in decreasing > orders if it wants to pack the BARs into an area as small as possible. > If you have BAR0 size 4K and BAR1 size 256M and BAR2 size 4K, then > allocating BAR0 from (for example) 0xe0000000 would yield BAR0 range of > 0xe0000000-0xe0000fff, BAR1 would be mapped to 0xf0000000 - 0xffffffff, > and BAR2 would not fit! > An optimal allocator must start from the biggest BARs first: > > BAR1 would fit at 0xe0000000-0xefffffff > BAR2 would fit at 0xf0000000-0xf0ffffff > BAR0 would fit at 0xf1000000-0xf1000fff > > Udi > > Donald White wrote: > >> >> Rune Torgersen wrote: >> >>> >>>> Subject: [U-Boot-Users] Please explain this code in drivers/pci.c >>> >>> >>> >>> >>>> The value of bar_response is 0xffff8008 which looks good. This >>>> gives bar >>> >>> >>> >>> size of >>> >>>> 0x8000 which also looks good. The value of mem is initially >>>> 0x90000000. >>> >>> >>> >>> So, >>> >>>> (mem - 1) = 0x8fffffff and (bar_size - 1) = 0x7fff). When these >>>> are or'd >>> >>> >>> >>> one gets >>> >>>> 0x8fffffff and adding 1 gives 0x90000000. This result is that the >>>> card is >>> >>> >>> >>> given 4 >>> >>>> address bases all at 0x90000000. >>> >>> >>> >>> >>> >>> If the card wants 4 different memory regiuons, I assume it has 4 BAR >>> registers? Each BAR must have the correct base address, so you have >>> to add >>> the size of the last region to the memory pointer before writing the >>> address to the next BAR >>> >>> >> >> I am not sure if you are trying to clarify the question or provide an >> answer. My complaint is that the code does not do what you say. I >> believe the code should provide four unique values for the four BARs, >> but it does not. Each gets the same value because the ORing logic >> does not succeed in doing a new base = old base + size. >> >> The logic envoked by CONFIG_PCI_PNP gets the calculation right. If >> someone is familiar with the code and can confirm that it is not >> behaving as intended, then I will do a patch. The ORing logic looks >> to me to be copied from the Linux kernel where the allocation starts >> at the top of the address range and proceeds downward, but maybe it is >> an attempt to force alignment. I don't know. >> >> Don >> >> >> >> ------------------------------------------------------- >> This SF.net email is sponsored by: ObjectStore. >> If flattening out C++ or Java code to make your application fit in a >> relational database is painful, don't do it! Check out ObjectStore. >> Now part of Progress Software. http://www.objectstore.net/sourceforge >> _______________________________________________ >> U-Boot-Users mailing list >> U-Boot-Users(a)lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/u-boot-users >> >

1 0

[U-Boot-Users] SIS55x based boards
by Frank 21 May '03

21 May '03

Has anybody ported u-boot to the SIS55x (x86) based boards... __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com

1 0

Re: [U-Boot-Users] file transfer server
by Wolfgang Denk 20 May '03

20 May '03

In message <2692A548B75777458914AC89297DD7DA021CCFDB(a)bronze.dolby.net> you wrote: > > Actually I want to run a server on the board, so that anyone on the > network can transfer files to it. So how easy would it be to implement > something like this. It is not exactly difficult, but it makes no sense either. U-Boot is a boot loader, not a file server. If you need server functions, run an OS. Boot into Linux, fire up inetd and a FTP or TFTP server. Voila. No need to implement any new features. 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 The ultimate barrier is one's viewpoint. - Terry Pratchett, _The Dark Side of the Sun_

1 0

[U-Boot-Users] file transfer server
by Dhanuka, Anupam 20 May '03

20 May '03

Hi all I am using uboot for the ebony board. I want to be able to transfer a new firmware image to the board over the network. I would like to be able to connect to some sort of a server running on the board (by interrupting the boot sequence) through a client running on a remote system and interactively provide the server with a firmware image which can then be written by the server onto flash. Can someone tell me how this can be done? Thanks Anupam This message (including any attachments) may contain confidential information intended for a specific individual and purpose. If you are not the intended recipient, delete this message. If you are not the intended recipient, disclosing, copying, distributing, or taking any action based on this message is strictly prohibited.

2 1

RE: [U-Boot-Users] [patch] MPC8266 March-C memory test
by Rune Torgersen 20 May '03

20 May '03

The slow version is written in C and should work on any platfrom. The fast version might work. Don't know if the 8xx is FPU compatible with the 82xx -----Original Message----- From: Nye Liu [mailto:nyet@mrv.com] Sent: Monday, May 19, 2003 5:09 PM To: Rune Torgersen Cc: U-BOOT (E-mail) Subject: Re: [U-Boot-Users] [patch] MPC8266 March-C memory test Should this also be portable to the 8xx[F]ADS platforms? I am currently debugging UPM/memory problems, and a real memory test would be invaluable :) On Mon, May 19, 2003 at 04:26:47PM -0500, Rune Torgersen wrote: > Patch to do full March-C- memory test on the MPC8266ADS board. > > Later on I will probably include it as a command, right now it runs as > test_dram() which is called first thing after SDRAM is initializes, and > before anything uses the SDRAM. > > Note: Fast version uses floating point assembly and is therefore PPC > specific. Generic version takes more than twice the amount of time to > complete. > (Fast version: ~50 sec on 256MB RAM, slow version ~1:50 on 256MB RAM) > ADS > Rune Torgersen > Software Developer > Innovative Systems > 1000 Innovative Drive > Mitchell, SD 57301 > Phone: 605-995-6120 > Fax: 605-995-0084 > email: runet(a)innovsys.com > www.innovsys.com > > > > > -- Nye Liu nliu(a)mrv.com (818) 772-6235x248 "Who would be stupid enough to quote a fictitious character?" -- Don Quixote

1 0

[U-Boot-Users] [PATCH] ARTOS boot support for u-boot
by Pantelis Antoniou 20 May '03

20 May '03

Wolfgang hi The following patch against u-boot-0.3.0 adds support for booting ARTOS images using u-boot. ARTOS is a custom in-house operating system in use by my company. We're in the process of moving some features of our in house boot-loader over to u-boot. I present the features to the mailing list in case someone else is working in anything similar, and would like to coordinate our efforts. o VLAN support and TOS configuration and support. o Two level access password support. o Different boot-modes. o Cisco router like command interface with history and command completion. o UDP-based same-LAN terminal access. o Factory testing framework. o More DHCP parameters support. o CDP support. o DHCP lease time information passed to the loaded kernel. Looking forward to hear your suggestions. Regards Pantelis diff -ruNb u-boot-0.3.0-orig/CREDITS u-boot-0.3.0/CREDITS --- u-boot-0.3.0-orig/CREDITS Wed Apr 16 10:56:20 2003 +++ u-boot-0.3.0/CREDITS Thu Apr 17 14:32:28 2003 @@ -286,3 +286,7 @@ E: azu(a)sysgo.de D: Overall improvements on StrongARM, ARM720TDMI; Support for Tuxscreen; initial PCMCIA support for ARM W: www.elinos.com + +N: Pantelis Antoniou +E: panto(a)intracom.gr +D: NETVIA board support, ARTOS support. diff -ruNb u-boot-0.3.0-orig/README u-boot-0.3.0/README --- u-boot-0.3.0-orig/README Wed Apr 16 10:56:20 2003 +++ u-boot-0.3.0/README Thu Apr 17 14:31:16 2003 @@ -343,7 +343,8 @@ CONFIG_GTH, CONFIG_RPXClassic, CONFIG_rsdproto, CONFIG_IAD210, CONFIG_RPXlite, CONFIG_sbc8260, CONFIG_EBONY, CONFIG_sacsng, CONFIG_FPS860L, - CONFIG_V37, CONFIG_ELPT860, CONFIG_CMI + CONFIG_V37, CONFIG_ELPT860, CONFIG_CMI, + CONFIG_NETVIA ARM based boards: ----------------- @@ -1726,7 +1727,7 @@ FPS850L_config Sandpoint8240_config sbc8260_config GENIETV_config TQM823L_config PIP405_config GEN860T_config EBONY_config FPS860L_config - ELPT860_config cmi_mpc5xx_config + ELPT860_config cmi_mpc5xx_config NETVIA_config Note: for some board special configuration names may exist; check if additional information is available from the board vendor; for @@ -2036,8 +2037,8 @@ * Target Operating System (Provisions for OpenBSD, NetBSD, FreeBSD, 4.4BSD, Linux, SVR4, Esix, Solaris, Irix, SCO, Dell, NCR, VxWorks, - LynxOS, pSOS, QNX; - Currently supported: Linux, NetBSD, VxWorks, QNX). + LynxOS, pSOS, QNX, ARTOS; + Currently supported: Linux, NetBSD, VxWorks, QNX, ARTOS). * Target CPU Architecture (Provisions for Alpha, ARM, Intel x86, IA64, MIPS, MIPS, PowerPC, IBM S390, SuperH, Sparc, Sparc 64 Bit; Currently supported: PowerPC). diff -ruNb u-boot-0.3.0-orig/common/cmd_bootm.c u-boot-0.3.0/common/cmd_bootm.c --- u-boot-0.3.0-orig/common/cmd_bootm.c Wed Apr 16 10:56:20 2003 +++ u-boot-0.3.0/common/cmd_bootm.c Wed Apr 16 13:24:15 2003 @@ -31,6 +31,7 @@ #include <image.h> #include <malloc.h> #include <zlib.h> +#include <environment.h> #include <asm/byteorder.h> #if (CONFIG_COMMANDS & CFG_CMD_DATE) || defined(CONFIG_TIMESTAMP) #include <rtc.h> @@ -104,6 +105,9 @@ int do_bootvx ( cmd_tbl_t *cmdtp, int flag, int argc, char *argv[] ); int do_bootelf (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[] ); #endif /* CFG_CMD_ELF */ +#ifdef CONFIG_PPC +static boot_os_Fcn do_bootm_artos; +#endif image_header_t header; @@ -326,6 +330,12 @@ addr, len_ptr, verify); break; #endif /* CFG_CMD_ELF */ +#ifdef CONFIG_PPC + case IH_OS_ARTOS: + do_bootm_artos (cmdtp, flag, argc, argv, + addr, len_ptr, verify); + break; +#endif } SHOW_BOOT_PROGRESS (-9); @@ -705,6 +715,88 @@ (*loader) (gd->bd, img_addr, consdev, cmdline); } +#ifdef CONFIG_PPC + +/* Function that returns a character from the environment */ +extern uchar (*env_get_char)(int); + +static void +do_bootm_artos (cmd_tbl_t *cmdtp, int flag, + int argc, char *argv[], + ulong addr, + ulong *len_ptr, + int verify) +{ + DECLARE_GLOBAL_DATA_PTR; + ulong top; + char *s, *cmdline; + char **fwenv, **ss; + int i, j, nxt, len, envno, envsz; + bd_t *kbd; + void (*entry)(bd_t *bd, char *cmdline, char **fwenv, ulong top); + image_header_t *hdr = &header; + + /* + * Booting an ARTOS kernel image + application + */ + + /* place data at the top of memory */ + top = gd->bd->bi_memstart + gd->bd->bi_memsize; + + /* first check the artos specific boot args, then the linux args*/ + if ((s = getenv("abootargs")) == NULL && (s = getenv("bootargs")) == NULL) + s = ""; + + /* get length of cmdline, and place it */ + len = strlen(s); + top = (top - (len + 1)) & ~0xF; + cmdline = (char *)top; + debug ("## cmdline at 0x%08lX ", top); + strcpy(cmdline, s); + + /* copy bdinfo */ + top = (top - sizeof(bd_t)) & ~0xF; + debug ("## bd at 0x%08lX ", top); + kbd = (bd_t *)top; + memcpy(kbd, gd->bd, sizeof(bd_t)); + + /* first find number of env entries, and their size */ + envno = 0; + envsz = 0; + for (i = 0; env_get_char(i) != '\0'; i = nxt + 1) { + for (nxt = i; env_get_char(nxt) != '\0'; ++nxt) + ; + envno++; + envsz += (nxt - i) + 1; /* plus trailing zero */ + } + envno++; /* plus the terminating zero */ + debug ("## %u envvars total size %u ", envno, envsz); + + top = (top - sizeof(char **)*envno) & ~0xF; + fwenv = (char **)top; + debug ("## fwenv at 0x%08lX ", top); + + top = (top - envsz) & ~0xF; + s = (char *)top; + ss = fwenv; + + /* now copy them */ + for (i = 0; env_get_char(i) != '\0'; i = nxt + 1) { + for (nxt = i; env_get_char(nxt) != '\0'; ++nxt) + ; + *ss++ = s; + for (j = i; j < nxt; ++j) + *s++ = env_get_char(j); + *s++ = '\0'; + } + *ss++ = NULL; /* terminate */ + + entry = (void (*)(bd_t *, char *, char **, ulong))ntohl(hdr->ih_ep); + (*entry)(kbd, cmdline, fwenv, top); +} +#endif + + #if (CONFIG_COMMANDS & CFG_CMD_BOOTD) int do_bootd (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[]) { @@ -826,6 +918,7 @@ case IH_OS_VXWORKS: os = "VxWorks"; break; case IH_OS_QNX: os = "QNX"; break; case IH_OS_U_BOOT: os = "U-Boot"; break; + case IH_OS_ARTOS: os = "ARTOS"; break; default: os = "Unknown OS"; break; } diff -ruNb u-boot-0.3.0-orig/include/image.h u-boot-0.3.0/include/image.h --- u-boot-0.3.0-orig/include/image.h Wed Apr 16 10:56:20 2003 +++ u-boot-0.3.0/include/image.h Wed Apr 16 10:56:51 2003 @@ -45,6 +45,7 @@ #define IH_OS_PSOS 15 /* pSOS */ #define IH_OS_QNX 16 /* QNX */ #define IH_OS_U_BOOT 17 /* Firmware */ +#define IH_OS_ARTOS 18 /* ARTOS */ /* * CPU Architecture Codes (supported by Linux) diff -ruNb u-boot-0.3.0-orig/tools/mkimage.c u-boot-0.3.0/tools/mkimage.c --- u-boot-0.3.0-orig/tools/mkimage.c Wed Apr 16 10:56:20 2003 +++ u-boot-0.3.0/tools/mkimage.c Wed Apr 16 10:56:51 2003 @@ -92,6 +92,7 @@ { IH_OS_PSOS, "psos", "pSOS", }, { IH_OS_QNX, "qnx", "QNX", }, { IH_OS_U_BOOT, "u-boot", "U-Boot", }, + { IH_OS_ARTOS, "artos", "ARTOS", }, { -1, "", "", }, };

2 10

[U-Boot-Users] [PATCH] Support for new I2C RTC
by Steven Scholz 20 May '03

20 May '03

Hi there, the attached patch adds support for a I2C RTC DS1338 for Dallas/Maxim. DS1307 and DS1338 are basicly the same, they only differ in their supply voltage. * Patches by Steven Scholz, 11 Apr 2003 - Add support for RTC DS1338 Cheers, Steven Index: README =================================================================== RCS file: /home/cvsroot/u-boot/README,v retrieving revision 1.1.1.1 diff -p -u -r1.1.1.1 README --- README 5 Apr 2003 00:13:43 -0000 1.1.1.1 +++ README 11 Apr 2003 10:42:22 -0000 @@ -638,6 +638,7 @@ The following options need to be configu CONFIG_RTC_MC146818 - use MC146818 RTC CONFIG_RTC_DS1307 - use Maxim, Inc. DS1307 RTC CONFIG_RTC_DS1337 - use Maxim, Inc. DS1337 RTC + CONFIG_RTC_DS1338 - use Maxim, Inc. DS1338 RTC CONFIG_RTC_DS164x - use Dallas DS164x RTC - Timestamp Support: Index: rtc/ds1307.c =================================================================== RCS file: /home/cvsroot/u-boot/rtc/ds1307.c,v retrieving revision 1.1.1.1 diff -p -u -r1.1.1.1 ds1307.c --- rtc/ds1307.c 6 Mar 2003 21:26:28 -0000 1.1.1.1 +++ rtc/ds1307.c 10 Apr 2003 11:27:09 -0000 @@ -25,7 +25,7 @@ /* * Date & Time support (no alarms) for Dallas Semiconductor (now Maxim) - * DS1307 Real Time Clock (RTC). + * DS1307 and DS1338 Real Time Clock (RTC). * * based on ds1337.c */ @@ -35,7 +35,8 @@ #include <rtc.h> #include <i2c.h> -#if defined(CONFIG_RTC_DS1307) && (CONFIG_COMMANDS & CFG_CMD_DATE) +#if (defined(CONFIG_RTC_DS1307) || defined(CONFIG_RTC_DS1338) ) && \ + (CONFIG_COMMANDS & CFG_CMD_DATE) /*---------------------------------------------------------------------*/ #undef DEBUG_RTC @@ -200,4 +201,4 @@ static unsigned char bin2bcd (unsigned i return (((n / 10) << 4) | (n % 10)); } -#endif /* CONFIG_RTC_DS1307 && (CFG_COMMANDS & CFG_CMD_DATE) */ +#endif /* (CONFIG_RTC_DS1307 || CONFIG_RTC_DS1338) && (CFG_COMMANDS & CFG_CMD_DATE) */

2 1

[U-Boot-Users] Loading from a CF card on the PCMCIA interface A P atch
by Rod Boyce 20 May '03

20 May '03

All, I have figured out my problem and have created a patch file to patch the file part_doc.c. This patch allows the command diskboot command to read from a partition inside an extended partition. <<part_dos.tar.gz>> Regards, Rod Boyce.

2 1

[U-Boot-Users] Patch to allow CFG_NO_FLASH & CFG_LOADS.
by Christophe.LINDHEIMER＠fr.thalesgroup.com 20 May '03

20 May '03

Hi. A little patch to allow the use of CFG_NO_FLASH & CFG_LOADS. Chris. --- u-boot-0.3.0/common/cmd_boot.c 2003-04-07 10:39:32.000000000 +0200 +++ u-boot-0.3.1/common/cmd_boot.c 2003-05-20 10:27:48.000000000 +0200 @@ -332,6 +332,7 @@ load_serial (ulong offset) case SREC_DATA3: case SREC_DATA4: store_addr = addr + offset; +#ifndef CFG_NO_FLASH if (addr2info(store_addr)) { int rc; @@ -340,9 +341,14 @@ load_serial (ulong offset) flash_perror (rc); return (~0); } - } else { + } else + + { +#endif memcpy ((char *)(store_addr), binbuf, binlen); - } +#ifndef CFG_NO_FLASH + } +#endif if ((store_addr) < start_addr) start_addr = store_addr; if ((store_addr + binlen - 1) > end_addr)

2 1

[U-Boot-Users] QNX
by Rune Torgersen 20 May '03

20 May '03

Hi Does anybody know how to get a QNX image to boot using u-boot (QNX 6.2.1) Rune Torgersen Software Developer Innovative Systems 1000 Innovative Drive Mitchell, SD 57301 Phone: 605-995-6120 Fax: 605-995-0084 email: runet(a)innovsys.com www.innovsys.com

3 4

RE: [U-Boot-Users] Please explain this code in drivers/pci.c
by Rune Torgersen 20 May '03

20 May '03

>Subject: [U-Boot-Users] Please explain this code in drivers/pci.c >The value of bar_response is 0xffff8008 which looks good. This gives bar size of >0x8000 which also looks good. The value of mem is initially 0x90000000. So, >(mem - 1) = 0x8fffffff and (bar_size - 1) = 0x7fff). When these are or'd one gets >0x8fffffff and adding 1 gives 0x90000000. This result is that the card is given 4 >address bases all at 0x90000000. If the card wants 4 different memory regiuons, I assume it has 4 BAR registers? Each BAR must have the correct base address, so you have to add the size of the last region to the memory pointer before writing the address to the next BAR

2 1

[U-Boot-Users] [PATCH] MPC8266ADS PCI support
by Rune Torgersen 19 May '03

19 May '03

Rune Torgersen Software Developer Innovative Systems 1000 Innovative Drive Mitchell, SD 57301 Phone: 605-995-6120 Fax: 605-995-0084 email: runet(a)innovsys.com www.innovsys.com

1 0

[U-Boot-Users] Please explain this code in drivers/pci.c
by Donald White 19 May '03

19 May '03

Group, Please help me to understand the following code. It occurs in drivers/pci.c in the function pci_hose_config_device(). I have ported U-Boot 0.3.0 and HHL 2.0 to our custom MPC8265A board. It has one device on the PCI bus. The driver develop was wanting a specific memory space allocation for the device. So I created a PCI configuration table with the memory base of 0x90000000. The card wants 4 regions 0f 0x8000 bytes in size. The driver writer thinks this should be 0x90000000, 0x90008000, 0x90010000 and 0x90018000. This brings us to the code snippet: bar_size = ~(bar_response & PCI_BASE_ADDRESS_MEM_MASK) + 1; bar_value = mem; mem = ((mem - 1) | (bar_size - 1)) + 1; The value of bar_response is 0xffff8008 which looks good. This gives bar size of 0x8000 which also looks good. The value of mem is initially 0x90000000. So, (mem - 1) = 0x8fffffff and (bar_size - 1) = 0x7fff). When these are or'd one gets 0x8fffffff and adding 1 gives 0x90000000. This result is that the card is given 4 address bases all at 0x90000000. Thanks for any help, Don

1 0

RE: [U-Boot-Users] U-boot for 8245 boards
by Karoliya, Abhishek 18 May '03

18 May '03

Thanks Chris for the message but that isnt the case really. On startup ,typing INFO does give "COP freeze (startup)" but on typing ti gives "trace" and typing go gives "TARGET : entered Debug state " and than typing info Debug entry cause gives <reserved 0>. thanks Abhishek -----Original Message----- From: Chris Hallinan [mailto:clh@net1plus.com] Sent: Saturday, 17 May 2003 12:58 AM To: Karoliya, Abhishek; u-boot-users(a)lists.sourceforge.net Cc: u-boot-users(a)lists.sourceforge.net Subject: RE: [U-Boot-Users] U-boot for 8245 boards Abhishek Karoliya wrote: > I am trying to port U-boot to a customised 8245 board . > For the Initial bring up , I am using a working U-Boot > for another very > similar board. The problem is that, using > BDI 2000 debugger , The telnet Interface reports it to be > at reset address > fff0 0100 all the time and no amount of ti or go works > When I use gdb it also reports it to be stuck there and a > step command > results in gdb reporting that a stop signal received . > I tried setting break points ahead but no use. > > The BDI set-up is working as i tried it with working > image of vxWorks loader > bootrom. This does not necessarily indicate your setup is correct, which it likely isn't. When you do an 'info' command from Telnet, after typing 'ti' or 'go', do you see "Debug entry cause " COP freeze (startup)? This generally indicates that the 8245 has entered check stop state due to a hardware/configuration/setup/procesor initialization issue. You will have to debug it. Regards, Chris Hallinan DS4.COM, Inc

2 1

[U-Boot-Users] MPC86xADS support
by Nye Liu 17 May '03

17 May '03

I just recieved the MPC86xADS eval board... anybody here have experience with it? -- Nye Liu nliu(a)mrv.com (818) 772-6235x248 "Who would be stupid enough to quote a fictitious character?" -- Don Quixote

1 1

[U-Boot-Users] About define CFG_CMD_LOADS and CFG_NO_FLASH.
by Christophe.LINDHEIMER＠fr.thalesgroup.com 17 May '03

17 May '03

Hi. Why can't I use CFG_CMD_LOADS & CFG_NO_FLASH. It doesn't compile because load_serial function ( in cmd_boot.c ) needs some function for flash access ( not sure to understand why ... ) Need to add #ifndef CFG_NO_FLASH in load_serial ?? Thanks Chris

2 1

[U-Boot-Users] U-boot for 8245 boards
by Karoliya, Abhishek 16 May '03

16 May '03

Hi, I am trying to port U-boot to a customised 8245 board . For the Initial bring up , I am using a working U-Boot for another very similar board. The problem is that, using BDI 2000 debugger , The telnet Interface reports it to be at reset address fff0 0100 all the time and no amount of ti or go works When I use gdb it also reports it to be stuck there and a step command results in gdb reporting that a stop signal received . I tried setting break points ahead but no use. The BDI set-up is working as i tried it with working image of vxWorks loader bootrom. Am I missing anything in u-boot compilation or anything to BDI to work or some problem with the code. Please illuminate... Thanks Abhishek

2 1

[U-Boot-Users] About ColdFire port
by Ales Makarov 16 May '03

16 May '03

Some time ago there was some ColdFire port (5272 only) of PPCBoot from Bernhard Kuhn. I haven't chance to try it, but I was very statisfied with PPCBoot on PPC405. Now we play with ColdFire 5407 and it would be nice to have the U-Boot here. How is it with ColdFire port of U-Boot? Thanks. Ales

1 0

[U-Boot-Users] linux image
by Nghiem, Tien 15 May '03

15 May '03

Hi everyone, I try to build a linux image for the MPC8260ADS: # cd <patch>/linux-2.4 # make MPC8260ADS_config I got the following error: # make MPC8260ADS_config make: *** No rule to make target `MPC8260ADS_config'. Stop. I got the same error if I did : # make ep8260_config make: *** No rule to make target `ep8260_config'. Stop. Could you tell me what I miss here? Thank you Tien Nghiem

2 1

[U-Boot-Users] The problem on porting to similar FADS860 board
by John 15 May '03

15 May '03

Hello list! I've checked the archives, but have not found anyone using the 860 with my problem. I have a MPC860 board ported from FADS860 board. ( TEXT_BASE is also 0x2800000, but IMMR is 0x2200000). I have vxworks run OK on it. But when I am porting U-Boot on it. I met booting problem on it. For Example as following: (ELDK1.0 + U-boot-0.3.0) -------------------------------------------------------- located in /cpu/mpc8xx/start.S .globl _start .extern testLed _start: lis r3, 0x220 /* my IMMR addr is 0x2200000 */ ori r3, r3, 0x0000 mtspr 638, r3 /*IMMR SPR is 638*/ bl testLed /* this is to light LEDs on board(PA0 - PA3)*/ ---------------------------------------------------------- located in /cpu/mpc8xx/cpu_init.c void testLed(void) { int i,k; for(k=0;k<5;k++) { * ( (volatile unsigned short *) (0x2200000 + 0x950) ) = 0xA000; /* light LED */ for (i=0; i<0xFFFF;i++) {;}; * ( (volatile unsigned short *) (0x2200000 + 0x950) ) = 0x0000; /* unlight LED */ for (i=0; i<0xFFFF;i++) {;}; }; }; When I build to *.bin and burn into bootrom flash, after power on, the LEDs of board are not lighting. But, I tested these codes under Vxworks Bootrom code (rominit.S), that's OK. maybe it is linking problem? I 'm confused. Could you like to help me or give me any comments ? Thanks in advance! John

2 5

[U-Boot-Users] 8260 64 bit access
by Rune Torgersen 15 May '03

15 May '03

Anybody know a efficient way of doing 64 bit loads, stores and compares? (on a 826x) I am doing a March-C based memory test, and need to get the number of instructions used in the loops down as much as possible. Rune Torgersen Software Developer Innovative Systems 1000 Innovative Drive Mitchell, SD 57301 Phone: 605-995-6120 Fax: 605-995-0084 email: runet(a)innovsys.com www.innovsys.com

2 1

Re: [U-Boot-Users] [mpc8250 pci]
by Wolfgang Denk 15 May '03

15 May '03

In message <002201bf8dc4$b8309000$240110ac@jsbae> you wrote: > This is a multi-part message in MIME format. > > ------=_NextPart_000_001F_01BF8E10.27DEFF90 > Content-Type: text/plain; > charset="Windows-1252" > Content-Transfer-Encoding: base64 > > SGFzIGFueW9uZSBkb25lIGFueSB3b3JrIHdpdGggVS1Cb290IG9yIGxpbnV4IGtlcm5lbCBvbiBt > cGM4MjUwIHByb2Nlc3Nvcj8NCkNhbiBhbnlib2R5IGV4cGxhaW4gbWUgODI1MCBwY2kgYnJpZGdl > IHNldHRpbmcgZm9yIGluaXRpYWwgLi4uLg0KaSB1c2UgTW9udGF2aXN0YSBMaW51eCBrZXJuZWwg ... Please do not post base64 encoded messages. Post plain text only. > ------=_NextPart_000_001F_01BF8E10.27DEFF90 > Content-Type: text/html; > charset="Windows-1252" > Content-Transfer-Encoding: base64 > > PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv > L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu ... Please no not post HTML. Please do not post base64 encoded messages. Post plain text only. Message unreadable, ignored. 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 Winners never talk about glorious victories. That's because they're the ones who see what the battlefield looks like afterwards. It's only the losers who have glorious victories. - Terry Pratchett, _Small Gods_

1 0

RE: [U-Boot-Users] [mpc8250 pci]
by Rune Torgersen 15 May '03

15 May '03

Should be very similar to the 8265 and 8266 (since they are using the 8250 init function) You could also try some of the existing board configs that use 8250. -----Original Message----- From: ??? [mailto:jsbae@imctech.co.kr] Sent: Tuesday, March 14, 2000 8:51 AM To: U-BOOT Subject: [U-Boot-Users] [mpc8250 pci] Has anyone done any work with U-Boot or linux kernel on mpc8250 processor? Can anybody explain me 8250 pci bridge setting for initial .... i use Montavista Linux kernel 2.4.17 ..but this kernel is referenced ep8260board... this kernel not consideration to pic bridge .. **************************************************************************** ******* ??? (? ? ?) (?)IMC?? ????? ??2? ??:042-822-3486 ??:042-822-3483 ????: 019-434-2975 Jang-Sik Bae R&D Development Team 2 IMC Tech Co.,Ltd. Korea Tel:+82-42-822-3486 FAX:+82-42-822-3483 Mobile:+82-19-434-2975 E-mail : jsbae(a)imctech.co.kr <mailto:jsbae@imctech.co.kr> MSN ID : Feb_Overset(a)hotmail.com <mailto:Feb_Overset@hotmail.com> **************************************************************************** *******

1 0

[U-Boot-Users] U-Boot on Alchemy AU1000
by Chris Hallinan 15 May '03

15 May '03

Has anyone done any work with U-Boot on the AU1000 processor? I would like to understand the level of effort required to port U-Boot to a board based on this processor. I am intimately familiar with PPCBoot/U-Boot on PowerPC platforms and numerous PPC implementations. However, I'm just starting the climb up the 'MIPS' learning curve. :) According to the AMD documentation, the AU1000 is based in the 'MIPS32' instruction set/architecture, which I presume is different from R3000/R4000 for which I see some level of support in the current U-Boot release. Grepping through a recent Linux source tree, I do see there is a specific CONFIG_CPU_* for MIPS32, and I've taken a brief look at where this is used. Specifically MMU and some CPU features appear to be handled differently from R3K/4K. I'd appreciate any input/feedback on what would be required to add support in U-Boot for this processor/architecture. Thanks in advance, Chris Hallinan DS4.COM, Inc.

1 0

[U-Boot-Users] SDRAM I2C Rom contents
by Roel Loeffen 15 May '03

15 May '03

Hello, I'm compiling U-Boot for the EVB64260, which reads the SDRAM settings from a I2C rom. We've build our own board an also the I2C Rom is installed. Where can I find what the I2C Rom contents layout should be for SDRAM information? Thx Roel

2 1

[U-Boot-Users] use and syntax of "=r"
by Paul,Kunal 15 May '03

15 May '03

hi all, i came across "=r" in the code of u-boot many times...can anybody explain me its use... i have been trying to copy a variable to SPR...will this help me.. thnx, kunal

1 0

[U-Boot-Users] patch to support intel e1000 family
by Mark Rakes 14 May '03

14 May '03

Wolfgang, etc. this patch adds support for Intel e1000 gig cards. Tested in u-boot with Sandpoint 8245 and the PRO/1000 MT Copper card (82546-based) and in ppcboot against that card, and its 82546 fiber equivalent. ran Lindent :) ran MAKEALL. did a diff against top of CVS. let me know if I need to make any patch modifications. enjoy, -mark rakes CHANGELOG entry: * Patch by Mark Rakes, 14 May 2003: Add e1000 driver

1 0

[U-Boot-Users] adding a command to write to regiters
by Paul,Kunal 14 May '03

14 May '03

hello all, i am workin on a custom board.i want to add commands for writing and reading to/from the CPU n PHY registers... can someone help me by telling me what all is required to be done...also i want to add a command to read and write boot n user flashes.... i need help on both. thnx... regards, kunal

1 0

[U-Boot-Users] using both AMD n Intel sync strata flashes on a board
by Paul,Kunal 14 May '03

14 May '03

hi all, i have a custom board wherein i am using an AMD flash as the bootflash and an INTEL synchronous strata flash(K3 n K18) as the user flash...can anybody help me with hoe to go about porting the u-boot for both... thnx, regards, kunal

1 0

[U-Boot-Users] walnut board
by Iser Flaum 14 May '03

14 May '03

first time user trying to run clone variation of the walnut bd. IBM demo board flash binary image (using PROM burner) runs (although having LAN problems to be debugged), and talks to the serial console ok. when trying to build the IBM provided source and makefile for this target, does not work (at least does not talk to console). already found one needed correction to the makefile.mak file .... the hbranch utility specified a wrong size flash (0x20000) instead of 0x80000 (512kB flash both on walnut demo and my clone). seeking information of other makefile.mak problems which may need correcting. it seems that the reset_entry block is being loaded at 0x2020 instead of 0x62020 (near the top of the flash). are there other alternative boot source/build tools available to get my board working? Iser Flaum (562) 926-6727 x113 iser(a)corelis.com

1 0

Re: [U-Boot-Users] IBM 440GP Ebony board: Gigabit ethernet adapter
by Mark Rakes 14 May '03

14 May '03

I "ported" a polling-based driver from the Etherboot project, which in turn had ported it from the Intel Linux (interrupt-based) driver. I've used it with both the 82546-based Dual Gig Copper adapter (pro/1000 MT) and the 82546-based Dual Gig Fiber adapter (don't know the model # off hand). We don't have a 64 bit environment, and we don't do PCI-X, so I'm not sure what that part will take, but this should be a start, hopefully... good luck, -m On Tuesday, May 13, 2003, at 03:33 PM, Dhanuka, Anupam wrote: > Hi Mark > > Thanks for your response. > > I am not sure what you mean when you say "via Etherboot via Linux Intel > Driver". Could you elaborate? > > Is the e1000 same as the Server Adapter (I want to use 64 bits)? What > would the differences be for PCI-x support? > > I am sorry but I am fairly new to this Boot Loader area. I am not used > to the terminology yet. > > Thanks > > Anupam > > > > -----Original Message----- > From: Mark Rakes [mailto:mrakes@vivato.net] > > I have a working e1000 driver (via Etherboot via Linux Intel driver) > for ppcboot on PCI (not PCI-X). > > I haven't submitted it back to the list as we're still using ppcboot > 2.0 and I hadn't taken the time to do the "port" the driver to u-boot > yet. > > I'll try to do that in today, if I can... > > no promises on pci-x, though... > -Mark > > > On Tuesday, May 13, 2003, at 02:26 PM, Wolfgang Denk wrote: > >> Dear Anupam, >> >> in message <2692A548B75777458914AC89297DD7DA021CCCC6(a)bronze.dolby.net> > >> you wrote: >>> >>> I have the IBM "Ebony' reference board with IBM 440GP processor. I >>> want >>> to use the Intel 1000/MT Gigabit Server Adapter as a network > interface >>> to load the OS image over the network. The adapter is connected to > the >>> PCI-X slot. I was wondering if U-boot has support for such an >> >> No,not yet (AFAIK). >> >>> arrangement. If not then where can I find more help and if I were to >>> develop the driver for this adapter myself, then how feasible would > it >>> be. >> >> It's a routine job for some of the developers on this list, and out >> of reach for others. Sorry, but I don't know your level of >> experience.

1 0

[U-Boot-Users] IBM 440GP Ebony board: Gigabit ethernet adapter
by Dhanuka, Anupam 13 May '03

13 May '03

Hi all I have the IBM "Ebony' reference board with IBM 440GP processor. I want to use the Intel 1000/MT Gigabit Server Adapter as a network interface to load the OS image over the network. The adapter is connected to the PCI-X slot. I was wondering if U-boot has support for such an arrangement. If not then where can I find more help and if I were to develop the driver for this adapter myself, then how feasible would it be. Help will be extremely appreciated. Anupam This message (including any attachments) may contain confidential information intended for a specific individual and purpose. If you are not the intended recipient, delete this message. If you are not the intended recipient, disclosing, copying, distributing, or taking any action based on this message is strictly prohibited.

3 2

RE: [U-Boot-Users] strataflash.c
by Tom Guilliams 13 May '03

13 May '03

In a x16 device in x8 mode, the portwidth should be 1. However, CFI detection in strataflash.c will not work in this mode. It will look for the CFI QRY at 0x10, 0x11, 0x12 offsets when they're actually at double that offset (portwidth = 2). I agree that the portwidth is not be used correctly in the case of a x16 device in x8 mode. For the meantime, the hack I've made will sustain me until I or someone else can add support for this chipset mode to the driver. Tom -----Original Message----- From: Frank Smith [mailto:smith@amirix.com] Sent: Sunday, May 11, 2003 4:51 PM To: Tom Guilliams; u-boot-users(a)lists.sourceforge.net Cc: Frank Smith Subject: Re: [U-Boot-Users] strataflash.c Hi, The more I look into strataflash.c, the more I'm starting to think that it doesn't support x16 devices in x8 mode. The problem I see is that the 'portwidth' value is used to drive two things -- offset multiplier, and side of data reads/writes to the flash device. On a pure x16 device, the offset multiplier is 2 and the size of the data read/writes is 2. So portwidth is 2. On an x16 device in x8 mode, however, the offset multiplier is 2, but the size of data read/writes is 1. What should portwidth be...? I think the offset multiplier and size of data read/writes should be driven by *different* values. Or am I overlooking something obvious? Thanks, Frank. ----- Original Message ----- From: "Tom Guilliams" <tguilliams(a)sbs.com> To: "'Frank Smith'" <smith(a)amirix.com>; <u-boot-users(a)lists.sourceforge.net> Sent: Friday, May 09, 2003 7:14 PM Subject: RE: [U-Boot-Users] strataflash.c > Frank, > > I can tell you I've had some problems with a x16 in x8 mode in > strataflash.c. Basically, the flash_detect_cfi() routine detects my > E28F128J3A chip as portwidth 2 (x16) and chipwidth 1 (x8). All the > CFI info > is read correctly. However, any write accesses to chip (programming > or > erasing) fail upon the calculated offset (it's incorrectly doubled because > of portwidth being 2). > > I had to manually force the portwidth to 1 (x8) after the > flash_get_size() routine to make everything behave for any flash > operations. > > I don't think the "detect" logic is correct in terms of port and chip width > for "some" devices. However, the author - Brad Kemp - has said he's > had success on numerous other flash width devices. > > Your problem sounds exactly like mine. For a hack fix, set > > info->portwidth = 1; > > for the last thing flash_get_size() does before returning the size. > > Tom > > -----Original Message----- > From: Frank Smith [mailto:smith@amirix.com] > Sent: Friday, May 09, 2003 1:00 PM > To: u-boot-users(a)lists.sourceforge.net > Subject: [U-Boot-Users] strataflash.c > > > > Hello, > > I have a board with a couple of Intel RC28F320J3A Strataflash devices. One > device is wired to x16 mode, the other to x8 mode. > > I'm trying to use the strataflash.c driver with these flash chips. > The driver detects the flash that's in x16 mode, but not the one in x8 > mode. So I'm digging through the code to try to figure out what's up. > I've been successful in avoiding dealing with flash programming code > up until now in my life..... > > If anyone knows anything about whether strataflash.c was designed to > work with x16 devices in x8 mode, I'd love to hear from you! From what > I've seen > so far, I'm tending to think that it doesn't. > > > Thanks, > Frank. > > > ------------------------------------------------------- > Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara > The only event dedicated to issues related to Linux enterprise > solutions www.enterpriselinuxforum.com > > _______________________________________________ > U-Boot-Users mailing list > U-Boot-Users(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/u-boot-users > > > ------------------------------------------------------- > Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara > The only event dedicated to issues related to Linux enterprise > solutions www.enterpriselinuxforum.com > > _______________________________________________ > U-Boot-Users mailing list > U-Boot-Users(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/u-boot-users >

1 0

RE: [U-Boot-Users] StrataFlash on PrPMC800
by Brad Kemp 13 May '03

13 May '03

Try ppmc8260/strataflash.c it autodetects the chip and port width Brad -----Original Message----- From: Mark.Lightfoot(a)sita.aero [mailto:Mark.Lightfoot@sita.aero] Sent: Tue 5/13/2003 2:13 PM To: u-boot-users(a)lists.sourceforge.net Cc: Subject: [U-Boot-Users] StrataFlash on PrPMC800 Hello, I've been working on a port of U-Boot for the Motorola PrPMC800 and I've come up against my first obstacle, CFI detection of the flash. The board implements two Intel 28F128J3 devices which, according to Motorola documentation, are each 8 bits wide residing on a 16 bit wide bus. I take that to mean they are interleaved to form a virtual 16 bit wide device. I've already taken care of mapping the devices into the CPU's address space. I borrowed the source code for flash support from the EVB64260 but it didn't work. It fails because it can determine the manufacture code Do any of the supported boards already support devices in a similar configuration? Could the source code possibly be reused for the PrPMC800? I don't know anything about how CFI works so I'm trying to avoid doing it from scratch. From the looks of it, it shouldn't be necessary to reinvent the wheel. But, if I've to start from scratch, anyone know of a good CFI tutorial. I've got the JEDEC docs but can make much of them yet. Regards, Mark. ><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< Mark Lightfoot - Software Designer - SITA 777 Walker's Line, Burlington, Ontario, Canada, L7N 2G1 905-681-5575 mark.lightfoot(a)sita.aero ><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< ------------------------------------------------------- Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara The only event dedicated to issues related to Linux enterprise solutions www.enterpriselinuxforum.com _______________________________________________ U-Boot-Users mailing list U-Boot-Users(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users

1 0

[U-Boot-Users] StrataFlash on PrPMC800
by Mark.Lightfoot＠sita.aero 13 May '03

13 May '03

Hello, I've been working on a port of U-Boot for the Motorola PrPMC800 and I've come up against my first obstacle, CFI detection of the flash. The board implements two Intel 28F128J3 devices which, according to Motorola documentation, are each 8 bits wide residing on a 16 bit wide bus. I take that to mean they are interleaved to form a virtual 16 bit wide device. I've already taken care of mapping the devices into the CPU's address space. I borrowed the source code for flash support from the EVB64260 but it didn't work. It fails because it can determine the manufacture code Do any of the supported boards already support devices in a similar configuration? Could the source code possibly be reused for the PrPMC800? I don't know anything about how CFI works so I'm trying to avoid doing it from scratch. From the looks of it, it shouldn't be necessary to reinvent the wheel. But, if I've to start from scratch, anyone know of a good CFI tutorial. I've got the JEDEC docs but can make much of them yet. Regards, Mark. ><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< Mark Lightfoot - Software Designer - SITA 777 Walker's Line, Burlington, Ontario, Canada, L7N 2G1 905-681-5575 mark.lightfoot(a)sita.aero ><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

1 0

[U-Boot-Users] How to debug u-boot?
by huasee 13 May '03

13 May '03

hi, How to debug u-boot?Is it necessarily to use emluator e.g.BDI2000? Can I use some software to debug (just as kgdb?)

1 0

[U-Boot-Users] porting problem on porting to similar FADS860 board
by John 12 May '03

12 May '03

Hello list! I've checked the archives, but have not found anyone using the 860 with my problem. I have a MPC860 board ported from FADS860 board. ( TEXT_BASE is also 0x2800000, but IMMR is 0x2200000). I have vxworks run OK on it. But when I am porting U-Boot on it. I met booting problem on it. For Example as following: (ELDK1.0 + U-boot-0.3.0) ---------------------------------------------------------------------------------------- located in /cpu/mpc8xx/start.S .globl _start .extern testLed _start: lis r3, 0x220 /* my IMMR addr is 0x2200000 */ ori r3, r3, 0x0000 mtspr 638, r3 /*IMMR SPR is 638*/ bl testLed /* this is to light LEDs on board(PA0 - PA3)*/ ---------------------------------------------------------------------------------------- located in /cpu/mpc8xx/cpu_init.c void testLed(void) { int i,k; for(k=0;k<5;k++) { * ( (volatile unsigned short *) (0x2200000 + 0x950) ) = 0xA000; /* light LED */ for (i=0; i<0xFFFF;i++) {;}; * ( (volatile unsigned short *) (0x2200000 + 0x950) ) = 0x0000; /* unlight LED */ for (i=0; i<0xFFFF;i++) {;}; }; }; When I build to *.bin and burn into bootrom flash, after power on, the LEDs of board are not lighting. But, I tested these codes under Vxworks Bootrom code (rominit.S), that's OK. maybe it is linking problem? I 'm confused. Could you like to help me or give me any comments ? Thanks in advance! John

1 0

[U-Boot-Users] linux doesn't boot when CS for initial cache disabled
by Thomas Schäfer 12 May '03

12 May '03

Here is what I did: I'm testing with an IBM Walnut board (PPC405GP) with u-boot 0.3.0 and 2.4.17 kernel from Montavista. After booting u-boot and loading the kernel via tftp, I submit the following commands on the console: => setdcr 12 0012: 00000004 ? 7 0012: 00000007 ? . => setdcr 13 0013: 400da000 ? 0 0013: 00000000 ? . This disables CS7, which is used for the temporary stack in my configuration. The kernel function start_here (arch/ppc/kernel/head_4xx.S) is the place where the MMU is used first. Setting a breakpoint (in my case at 0xc00022d0) and trying to trace from this point with my BDI2000 results in a data machine check interrupt: BDI>bi 0xc00022d0 Breakpoint identification is 0 BDI>go - TARGET: target has entered debug mode BDI>info Target state : debug mode Debug entry cause : instruction breakpoint Current PC : 0xc00022d0 Current CR : 0x24004004 Current MSR : 0x00001030 Current LR : 0x0000001c BDI>ti Target state : debug mode Debug entry cause : JTAG stop request Current PC : 0x00000280 Current CR : 0x28004004 Current MSR : 0x00000000 Current LR : 0xc0002b34 # Step timeout detected BDI> Unfortunately I have no idea why this happens. Looking at the register contents I found that the address of the temporary stack (0x40000000) is still stored in r2, but this should have no effect on booting the kernel??? BDI>rd GPR00: c00022d0 07f9f5e8 40000000 c10003c0 GPR04: c0000000 00000000 007ffc00 007ffc0e GPR08: 07fc9f10 000186a0 00000003 00000002 GPR12: 00000000 c01605b0 07fe5800 00000000 GPR16: 00000001 007ffc0e 007ffc00 ffffffff GPR20: 00000000 07fe2398 07f9fe88 00000002 GPR24: 00000000 00000000 007ffb90 007ffc0e GPR28: 007ffc00 00000000 00000000 007ffb90 CR : 24004004 MSR: 00001030 BDI> Any ideas? Best regards, Thomas Schaefer ____________________________________ GIGA STREAM - UMTS Technologies GmbH Konrad-Zuse-Str. 7 66115 Saarbrücken Tel.: + 49 (0)681 / 95916 - 203 Fax: + 49 (0)681 / 95916 - 100 E-mail: tschaefer(a)giga-stream.de

1 0

RE: [U-Boot-Users] Change file location
by Rune Torgersen 12 May '03

12 May '03

>> There is currently a huge cludge, because the /cpu/mpc8260/pci.c is >> different for different boards based on the 826x cpu's. > >Oops?? We use the current version of cpu/mpc8260/pci.c omn several >boards already, without #ifdef's. > >> The better solution would be to move this file into the board specific >> directories. >> If not, I would have to do #ifdef around the whole file. > >Can you please explain why you think this is a board specific file? Because the PCI Maemory and IO map is defined there, and it does depend a bit on how you want the board set up. I guess it can be used for multiple boards if the memory map should be the same. I know the reason Andy changed the pci.c memory map, was to get a simpler memory layout in linux. Here is his motivation for changing it: * This file is a bit of a problem since the PCI memory map is hardcoded here in code common to all MPC8260 targets, but one memory map may not necessarily be appropriate for all targets. For now I just changed the hardcoded memory map to one that I like better. This probably broke the PM826 u-boot port. The memory map definition could be #ifdef'd for each board, or the memory map definition could be moved to the board configuration header file. My motivation here was to move the PCI I/O space from 0xA0000000 to 0xF4000000. Having all the I/O regions above 0xF0000000 allows Linux to efficiently map them all with one BAT register.

2 1

RE: [U-Boot-Users] MMU setup in u-boot
by Jerry Van Baren 12 May '03

12 May '03

Sorry, you will have to go complex if you want to reach all your memory. gvb At 12:29 PM 5/12/2003 -0400, johny122(a)hotmail.com wrote: >Hi, > >Our processor is MPC7450. We have only one BAT left to setup SDRAM. The >other three BAT are used for L3, flash and PCI, and we have 1G memory. I am >thinking about using Page Address Translation method using hashing functions >as described in the Motorola green book. This method is quite complicated >and I dont know where to start with. Any of your feed back is appreciated. > >Thanks. ********************************************************************** This e-mail and any files transmitted with it may be confidential and may be legally privileged or otherwise exempt from disclosure under applicable law. This e-mail and its files are intended solely for the individual or entity to whom they are addressed and their content is the property of Smiths Aerospace. If you are not the intended recipient, please do not read, copy, use or disclose this communication. If you have received this e-mail in error please notify the e-mail administrator at postmaster(a)smiths-aerospace.com and then delete this e-mail, its files and any copies. This footnote also confirms that this e-mail message has been scanned for the presence of known computer viruses. Smiths addresses are changing! The new addresses are of the form firstname.lastname(a)smiths-aerospace.com. Please update your address books! Please begin using the new form immediately. ***********************************************************************

1 0

[U-Boot-Users] MMU setup in u-boot
by john ashfield 12 May '03

12 May '03

Hi, u-boot setups MMU for maximum of 256M memory using Block Address Translation. Do you have any idea how to setup MMU for more than 256M (for example 1G of memory)? Thanks _________________________________________________________________ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail

4 4

RE: [U-Boot-Users] MMU setup in u-boot
by john ashfield 12 May '03

12 May '03

Hi, Our processor is MPC7450. We have only one BAT left to setup SDRAM. The other three BAT are used for L3, flash and PCI, and we have 1G memory. I am thinking about using Page Address Translation method using hashing functions as described in the Motorola green book. This method is quite complicated and I dont know where to start with. Any of your feed back is appreciated. Thanks. _________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail

1 0

[U-Boot-Users] ARM & Ethernet PHY ???
by Steven Scholz 12 May '03

12 May '03

Hi there, is there support for the LXT971 Ethernet PHY on ATM920T based boards ??? How about arm-linux? Thanks a million, Steven

2 1

[U-Boot-Users] Re: what means this symbol "@"?
by Wells, Charles 12 May '03

12 May '03

>I've never figured out why someone would want to use addi instead of ori in >the second instruction of the load sequence. > >gvb Jerry, The only authoritative explanation I've seen comes from IBM's _The_PowerPC_Compiler_Writer's_Guide_; Steve Hoxey, et.al., 1/1996. Section 3.2.3.1 (p. 48-49) is entitled Loading a Constant into a Register. After discussing the different techniques, they say: "The add instructions are preferred to logical instructions because future PowerPC implementations may have a three-input adder, which permits executing the preceding two instructions (and other forms of add-feeding-add) in parallel, even though they are not independent." If your hand-crafted assembly language is being used to optimize an inner loop, then it may make a difference. If it's used in some one-time initialization code, it doesn't matter. BTW, the CWG is a wonderfully entertaining resource for folks that want to better understand the PowerPC architecture. It's available at: <http://www-3.ibm.com/chips/techlib/techlib.nsf/techdocs/852569B20050FF77852 56996007558C6> Regards, Charlie

1 0

RE: [U-Boot-Users] strataflash.c
by Tom Guilliams 12 May '03

12 May '03

Frank, I can tell you I've had some problems with a x16 in x8 mode in strataflash.c. Basically, the flash_detect_cfi() routine detects my E28F128J3A chip as portwidth 2 (x16) and chipwidth 1 (x8). All the CFI info is read correctly. However, any write accesses to chip (programming or erasing) fail upon the calculated offset (it's incorrectly doubled because of portwidth being 2). I had to manually force the portwidth to 1 (x8) after the flash_get_size() routine to make everything behave for any flash operations. I don't think the "detect" logic is correct in terms of port and chip width for "some" devices. However, the author - Brad Kemp - has said he's had success on numerous other flash width devices. Your problem sounds exactly like mine. For a hack fix, set info->portwidth = 1; for the last thing flash_get_size() does before returning the size. Tom -----Original Message----- From: Frank Smith [mailto:smith@amirix.com] Sent: Friday, May 09, 2003 1:00 PM To: u-boot-users(a)lists.sourceforge.net Subject: [U-Boot-Users] strataflash.c Hello, I have a board with a couple of Intel RC28F320J3A Strataflash devices. One device is wired to x16 mode, the other to x8 mode. I'm trying to use the strataflash.c driver with these flash chips. The driver detects the flash that's in x16 mode, but not the one in x8 mode. So I'm digging through the code to try to figure out what's up. I've been successful in avoiding dealing with flash programming code up until now in my life..... If anyone knows anything about whether strataflash.c was designed to work with x16 devices in x8 mode, I'd love to hear from you! From what I've seen so far, I'm tending to think that it doesn't. Thanks, Frank. ------------------------------------------------------- Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara The only event dedicated to issues related to Linux enterprise solutions www.enterpriselinuxforum.com _______________________________________________ U-Boot-Users mailing list U-Boot-Users(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users

2 1

[U-Boot-Users] newbie's error on build u-boot
by Zhao Hongda 11 May '03

11 May '03

I'm trying to build u-boot with arm-linux-gcc(gcc 3.2.1, binutils 2.13.90.16, glic 2.3.1), but got the following error: cpu/xscale/start.S:Assembler messages: cpu/xscale/start.S:145 Error: internal_relocation(type: OFFSET_IMM) not fixed up <somethig like above> what should I do to solve this? Hongda Zhao by the way: it can be builded right under arm-linux-gcc 2.95.3.

1 0

[U-Boot-Users] linux doesn't boot when CS for initial cache disabled
by Thomas Schäfer 10 May '03

10 May '03

Hi all, I want to port u-boot to a custom board based on the walnut board where CS0-CS7 are in use by separate chips. I tried to program CS4, which is used for temporary stack and data before relocation, with the settings for a chip after the relocation has been done. u-boot seems to work fine with this setting, global data structure and board info structure are located in RAM and contain the correct values. Loading a kernel via tftp works without problems. As soon as I'm trying to boot the kernel, the system hangs after the kernel has been uncompressed. Trying to debug the kernel boot sequence, I found that the function reloc_offset seems to hang in an endless loop. My question is: why is that CS for the temporary stack of u-boot important for the start sequence of the linux kernel? The Readme says that this stack and data area is only used before relocation of u-boot. Any comments would be appreciated Best regards, Thomas Schäfer ____________________________________ GIGA STREAM - UMTS Technologies GmbH Konrad-Zuse-Str. 7 66115 Saarbrücken Tel.: + 49 (0)681 / 95916 - 203 Fax: + 49 (0)681 / 95916 - 100 E-mail: tschaefer(a)giga-stream.de

3 2

[U-Boot-Users] Change file location
by Rune Torgersen 10 May '03

10 May '03

Hi I am in the process of celaning up a patch to get PCI support to work on a MPC8266ADS board from Motorla. (Patch written by Andy Lowe from MontaVista) There is currently a huge cludge, because the /cpu/mpc8260/pci.c is different for different boards based on the 826x cpu's. The better solution would be to move this file into the board specific directories. If not, I would have to do #ifdef around the whole file. Rune Torgersen Software Developer Innovative Systems 1000 Innovative Drive Mitchell, SD 57301 Phone: 605-995-6120 Fax: 605-995-0084 email: runet(a)innovsys.com www.innovsys.com

2 1

Re: [U-Boot-Users] [u-boot 3.0 porting to mpc8260 board]
by Wolfgang Denk 10 May '03

10 May '03

In message <001301bf88dd$03fdd520$240110ac@jsbae> you wrote: > This is a multi-part message in MIME format. > > ------=_NextPart_000_0010_01BF8928.73BCE680 > Content-Type: text/plain; > charset="ks_c_5601-1987" > Content-Transfer-Encoding: base64 > > SGVsbG8gYWxsLA0KSSd2ZSBnb3QgYSBwcm9ibGVtIHdpdGggcG9ydGluZyB1LWJvb3QgMy4wIG9u > IGFuIGVtYmVkZGVkIHN5c3RlbShtcGM4MjUwKQ0KaSB3YW5uYSBpbml0aWFsaXplIHBjaSBidXQg > LCAgaSBjYW4ndCBmaW5kIHBjaV9pbml0X2JvYXJkKCkgLi4uLnRoaXMgZnVuY3Rpb24gY2FsbGVk > IGJ5IHBjaV9pbml0KCkuDQphbmQgd2hlbiBpIGNhbGwgcGNpX21wYzgyNTBfaW5pdCgpPz8gaW4g > Y3B1L21wYzgyNjAvcGNpLmMNCg0KVGhhbmsgeW91Li4uLi4NCioqKioqKioqKioqKioqKioqKioq > KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq > KioqKioqDQoguejA5b3EICjb0SDt/iDj1SkNCiAowdYpSU1DxdfFqSC/rLG4sLO537rOILCzud8y > xsANCiDA/MitOjA0Mi04MjItMzQ4NiANCiDG0b26OjA0Mi04MjItMzQ4MyANCiDI3rTrwPzIrTog > MDE5LTQzNC0yOTc1DQogDQogSmFuZy1TaWsgQmFlIA0KIFImRCBEZXZlbG9wbWVudCBUZWFtIDIN > CiBJTUMgVGVjaCBDby4sTHRkLiBLb3JlYQ0KIFRlbDorODItNDItODIyLTM0ODYgDQogRkFYOis4 > Mi00Mi04MjItMzQ4MyANCiBNb2JpbGU6KzgyLTE5LTQzNC0yOTc1DQogDQogRS1tYWlsICA6IGpz > YmFlQGltY3RlY2guY28ua3INCiBNU04gSUQgOiBGZWJfT3ZlcnNldEBob3RtYWlsLmNvbQ0KDQoq > KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq > KioqKioqKioqKioqKioqKioqKioqKioqKg0KDQo= Please do not post base64 encoded messages to the list. Post plain text only. > ------=_NextPart_000_0010_01BF8928.73BCE680 > Content-Type: text/html; > charset="ks_c_5601-1987" > Content-Transfer-Encoding: base64 > > PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv > L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu > dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T ... Please do not post base64 encoded messages to the list. Please do not post HTML to the list. Post plain text only. Message unreadable, ignored. 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 GUIs are virtually useless. Learn tools. They're configurable, scriptable, automatable, cron-able, interoperable, etc. We don't need no brain-dead winslurping monolithic claptrap. -- Tom Christiansen in 371140df@csnews

1 0

Re: [U-Boot-Users] CodeWarrior U-Boot debug
by Jerry Van Baren 10 May '03

10 May '03

Sorry, no direct help on CodeWarrior but... stuck in the FP exception would tend to indicate a memory, probably a SDRAM, problem. This is a classic problem: SDRAM appears to work, but is misconfigured and cache burst reading doesn't work properly. This causes a lot of 0xFFs in the instruction stream and these map into FP instructions, causing the FP exception. Reading and writing RAM using your CodeWarrior is NOT a good test of SDRAM. Most often you need to do a burst read for it to fail. Burst reads occur (at this point in the game) only when doing an instruction fetch with the instruction cache enabled. Try running with instruction cache turned off. If it runs slowly but steady :-), you are in the 99% probability it is a SDRAM initialization issue. gvb At 02:25 PM 5/1/2003 -0400, RL(a)prodrive.nl wrote: >Hello, > >Has anyone of you ever used MetroWerks CodeWarrior to debug U-Boot? > >After I've succesfuly compiled the u-boot ELF and binairy I've programmed my >flash with the binairy. > >Next, I've made a CodeWarrior project using the ELF file output of the GNU >Compiler. > >I can connect to the PPC and I can view memory, but when I break the running >process, the cpu is always stuck at address 0x800 (floating point >exception). > >Also I cannot view the code in CodeWarrior?? > >Can someone help me? > >Thx Roel > > > > >------------------------------------------------------- >This sf.net email is sponsored by:ThinkGeek >Welcome to geek heaven. >http://thinkgeek.com/sf >_______________________________________________ >U-Boot-Users mailing list >U-Boot-Users(a)lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/u-boot-users ********************************************************************** This e-mail and any files transmitted with it may be confidential and may be legally privileged or otherwise exempt from disclosure under applicable law. This e-mail and its files are intended solely for the individual or entity to whom they are addressed and their content is the property of Smiths Aerospace. If you are not the intended recipient, please do not read, copy, use or disclose this communication. If you have received this e-mail in error please notify the e-mail administrator at postmaster(a)smiths-aerospace.com and then delete this e-mail, its files and any copies. This footnote also confirms that this e-mail message has been scanned for the presence of known computer viruses. Smiths addresses are changing! The new addresses are of the form firstname.lastname(a)smiths-aerospace.com. Please update your address books! Please begin using the new form immediately. ***********************************************************************

2 1

[U-Boot-Users] strataflash.c
by Frank Smith 09 May '03

09 May '03

Hello, I have a board with a couple of Intel RC28F320J3A Strataflash devices. One device is wired to x16 mode, the other to x8 mode. I'm trying to use the strataflash.c driver with these flash chips. The driver detects the flash that's in x16 mode, but not the one in x8 mode. So I'm digging through the code to try to figure out what's up. I've been successful in avoiding dealing with flash programming code up until now in my life..... If anyone knows anything about whether strataflash.c was designed to work with x16 devices in x8 mode, I'd love to hear from you! >From what I've seen so far, I'm tending to think that it doesn't. Thanks, Frank.

1 0