April 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] 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

[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

RE: [U-Boot-Users] Help, how do I decouple the reset address from the hw config word on ppc82xx
by Mark Doherty 30 Apr '03

30 Apr '03

Thanks for the prompt Wolfgang, It took a little bit of time to think through the u-boot lifecycle but now it seems quite straight forward and works very well. I've been able to glean quite a bit of info from past posts but there doesn't seem any way to search the archives, do you have any suggestions? Thx Mark Doherty Senior Engineer ************************************** arca technologies 2 Trench Road Mallusk, Belfast Northern Ireland BT36 4TY ************************************* -----Original Message----- From: Wolfgang Denk [mailto:wd@denx.de] Sent: 14 April 2003 10:17 To: Mark Doherty Cc: 'u-boot-users(a)lists.sourceforge.net' Subject: Re: [U-Boot-Users] Help, how do I decouple the reset address from the hw config word on ppc82xx In message <9901EE1E8F8BD3119109009027A1B5F596AD5B@DIGINET2> you wrote: > > > > I've been attempting to build u-boot to run on an embedded planet ep8260 > > board reasonably sucessfully, however my board profile has flash starting > > at 0xFF000000, the reset vector is of course at 0xFFF00100. I've been There are two errors in this sentence. Forst, there is no fixed physcal address map. The address map of your system is defined by whatever you program into your memory controller registers. You don't have to map you flash at 0xFF000000; you could chose any other address as well (but this isn't your problem here). The second error is the "of course at 0xFFF00100". It could be at 0x100 as well, depending on the CIP/BMS settings in your HRCW. (Actually 0x100 seems to be a much more "natural" setting to me). > > scanning the code and build files looking for a reference to decouple the > > hardware configuration word at 0xFF00000 and the reset vector at > > 0xFFF00100 so far with no real sucess. This is your third error. You try to do something that is not necessary. Read the User's Manual about how the memory controller works, especially how boot memory space is defined (initial settings of BR0[BA]). 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 He'd heard her use that sweet, innocent tone of voice before. It meant that, pretty soon, there was going to be trouble. - Terry Pratchett, _Truckers_

1 0

Re: [U-Boot-Users] DiskOnChip, filesystems, and other booting options
by Wolfgang Denk 30 Apr '03

30 Apr '03

Dear Udi, in message <01qhav4dc6n97kctt8ob8f9qsjrva8v3sm(a)4ax.com> you wrote: > > Yes, I know about these - what I meant was that the D.O.C support is > still at > the sector level, without any filesystem support. Right. IMHO all filesystem stuff for U-Boot should be split into a separate layer (standalone applications acting as second stage bootstrap loaders). > As far as I know (correct me if I'm wrong), NFTL does block-level > remapping of > bad blocks as well as wear levering by constantly changing the > logical<>physical sector mapping on each write (so that if you write the > same > "logical" sector 1000 times it would spread over all the flash). So they claim to do. > If my understanding is accurate, how can I use the U-Boot raw sectors > without > disturbing the NFTL mapping that is handled by the Linux MTD package? I think that the "binary partition" is not subject to this, i. e. you can do direct I/O with the binary partition on the DoC. > Besides, I've peeked into the D.O.C code in U-boot and it's full of NFTL > references. In fact, as far as I can see, binary partitions are part of > NFTL. Yes. > I've been looking at the files in fs/fdos/... and the CMD_FDC, CMD_FDOS > code > which calls them., and I see it contains complete code to read a FAT > filesystem. Something to be cleaned up and implemented in a more general way... > I understand from the above that I don't need it, but just for the sake > of > understanding - couldn't I drop the NFTL+normal filesystem and use JFFS2 > over > the raw D.O.C sectors, since JFFS2 does bad block mapping and wear > levering > (or does it??) I don't know if it is possible to extend the size of the binary partition to cover the whole device. > OK, so where to I stand now? > 1. My kernel correctly identifies the D.O.C but for some reason manages > to > mount it only partially. /dev/mtdchar0 is non functional, but /dev/nftla > seems > to work between reboots. I can correctly partition the D.O.C using fdisk, > and > the format is kept when I leave fdisk and re-run it, btu once I reboot, > all > the partitioning done is lost. That rings a bell to me. We fixed exactly such a problem once. In the old version of the code some internal data structures of the NFTL driver, which are initialized only at boot-time, become invalid after you run nftl_format. See my message "DOC / NFTL problem, and fix" from Aug 28, 2002, to the MTD mailing list: http://lists.infradead.org/pipermail/linux-mtd/2002-August/005853.html I don't know if they ever accepted the patch, and/or if it is included with your version of the MTD tools. Just in case I attach this patch again below. > I think this part of my questions should be sent to the MTD list I guess. Agreed. 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 Do not underestimate the value of print statements for debugging.

2 3

Re: [U-Boot-Users] How To Use gdb w/ u-boot source tree
by Wolfgang Denk 29 Apr '03

29 Apr '03

In message <EGEGIJHKDKJGAJMGIDPNOEKACDAA.jwalden(a)digitalatlantic.com> Jerry Walden wrote: > > Sorry - I did not make myself clear - > Instead of using gdb as a command line debugger, I was hoping to > use an IDE style debugger that can show source (comments etc), so > I can do source level debugging. That does not make any difference, or does it? fro example, use DDD as GUI frontend with GDB - but it's still GDB that will actually perform the debugging, so why shoud it behave differently? [Please, keep the list Cc:ed for the benefit of other readers...] Best regards, and a Happy New Year! 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 Time is fluid ... like a river with currents, eddies, backwash. -- Spock, "The City on the Edge of Forever", stardate 3134.0

5 43

Re: [U-Boot-Users] new to the u-boot community
by Howard King 29 Apr '03

29 Apr '03

In the README documentation, in the section it talked about port u-boot to your hardware platform, step 2, - board.c: where are those functions called? - flash.c: I can't find it on other board's directory - u-boot.lds: what is this file? WHo use it? Thanks.

2 2

[U-Boot-Users] Re: U-boot i386 port
by Daniel Engstr�m 29 Apr '03

29 Apr '03

On 2003.04.29 16:12 Tony Chu wrote: Tony, (I am re-adding the U-boot list beacuse this might interest other people trying to use the i386 port of U-boot). > I found the reason why my board halt when boot linux: Good. > our custom Pentium 2 board is based on IBM PC arch. > so. the address A0000-FFFFF is readonly. > but u-boot install the realmode interrupt handler at > F0000. so... actually. the handler can not be copy to > there. so when excute int xx > in setup.S, my board halt. This is really a small BIOS emulator, it lives in shadow RAM at 0xf0000 because it is the space where the BIOS would have been if we had one. > I am now wonder this feature(A0000-FFFFF readonly) is > a problem to boot linux kernel or not??? You should be able to use 0xf0000-0xfffff with any modern chipset, you only have to use the BIOS shadow feature in the chip-set to map ram into that region, before you use it. The ability to enable shadow ram is required in the PCI spec. > and now, I plan to move the realmod interrupt handler > to address: 98000(at 90000 + MAX_SETUP_SIZE. any > problem??? This area is used by the BIOS for the extended BIOS data area on a standard PC, the only use that I think linux make of the space is to read the PS/2 equipment word or something like this. Using this space for the BIOS emulation code should work unless you want to implement full BIOS compatability (to boot Windows for example). /Daniel

1 0

[U-Boot-Users] "Porting armboot epxa1db to u-boot question
by Andrea Sorio 29 Apr '03

29 Apr '03

Hi I'm trying to port the armboot epxa1db version to U-Boot. I made all the change necessary (I guess :-)). I can compile it but i'm not able to link it. The linker reports these messages: arm-linux-ld -Bstatic -T /home/sorio/Devel/UBoot/u-boot-0.3.0/board/epxa1db/u-boot.lds -Ttext 0x00000 cpu/epxa/start.o /home/sorio/Devel/UBoot/u-boot-0.3.0/tools/quartus/libraries/software/boot/libboot_xa_ads.a\ --start-group board/epxa1db/libepxa1db.a cpu/epxa/libepxa.a lib_arm/libarm.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 arm-linux-ld: Error: interrupts.o compiled for EABI version 0, whereas u-boot is compiled for version 1 File format not recognized: failed to merge target specific data of file cpu/epxa/libepxa.a(interrupts.o) arm-linux-ld: Error: board.o compiled for EABI version 0, whereas u-boot is compiled for version 1 File format not recognized: failed to merge target specific data of file lib_arm/libarm.a(board.o) arm-linux-ld: Error: net.o compiled for EABI version 0, whereas u-boot is compiled for version 1 File format not recognized: failed to merge target specific data of file net/libnet.a(net.o) arm-linux-ld: Error: bootp.o compiled for EABI version 0, whereas u-boot is compiled for version 1 File format not recognized: failed to merge target specific data of file net/libnet.a(bootp.o) arm-linux-ld: Error: rarp.o compiled for EABI version 0, whereas u-boot is compiled for version 1 File format not recognized: failed to merge target specific data of file net/libnet.a(rarp.o) ........ I'm not able to understand this error. Could someone be so kind as to tell me a hint? Thank you in advance Andrea Sorio -- Andrea Sorio Hardware & Software Engineer Free Consultant http://www.cocay.it email: a.sorio(a)cocay.it Phone: 348 8703449

2 1

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

29 Apr '03

Kenneth, what type of (32 bit wide device) SDRAM is the ECC configuration piece for? As far as I understood the walnut manual, DIMM's are always designed as 64 bit devices (which can be used as 32 bit devices, but not in ECC mode). 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

1 0

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

29 Apr '03

Wolfgang, please find attached a patch for the cpu/ppc4xx/spd_sdram file. The ECC configuration code in function spd_sdram is changed so that 72 bit ECC DIMM's are used in non-ECC mode. Using those DIMM's in ECC mode doesn't work on the walnut board. If working, it would make probably no sense, because only the half of the DIMM size can be used in ECC mode. CFG_MONITOR_LEN in include/configs/WALNUT405.h was changed to 256, because 192 was too small for the configuration provided with u-boot-0.3.0 Maybe the patch is of some use for the project. 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

1 0

[U-Boot-Users] U-boot/EVB64360
by Eliasson, Anders (IndSys, GEFanuc, VMIC) 28 Apr '03

28 Apr '03

Hello, I saw a reference to work being done to get an EVB64360 to boot. I am curious as to how far that has progressed and if there are any files to look at yet. I'm working with this board now and having dismal success so far. BTW, with respect to an earlier post of mine about errors in astest.c when building u-boot, I just 'capped' test and u-boot built. Thanx, Anders VMIC anders.eliasson(a)gefanuc.com

1 0

[U-Boot-Users] Building u-boot
by Eliasson, Anders (IndSys, GEFanuc, VMIC) 28 Apr '03

28 Apr '03

Hello, I finally got my Linux system complete with cross-compiler set up last week and took a shot at building u-boot this morning. Things went along nicely until; astest.c - in main - 'true' undeclared Ok, so I search the mailing list and find that a previous question about astest.c exists, that astest.c is not considered all that important ( by the responder ), and that the question doesn't address what I see. Once again, I suspect my set up. Maybe something in my GDB area? Any help will be appreciated, as always. Thanx, Anders VMIC anders.eliasson(a)gefanuc.com

1 0

[U-Boot-Users] Re: u-boot i386 port
by Daniel Engström 28 Apr '03

28 Apr '03

On 2003.04.28 07:09 zhu.zuoliang(a)zte.com.cn wrote: > Zhu Zuoliang > > Thanks a lot for your help!!!! U-boot is now runing on my custom Pentium > 2 board now, but the Linux Kernel still can not boot yet. > > I compiled a bzImage , download to u-boot, it halt after print: Start > Kernel.... > this is the problem of my Linux Kernel ? or my u-boot still has problem? > or both????? The obvius question is: have you configured serial console correctly in linux? It cold also be a problem with the load address you use, not all values will work, I use 0x100000 wich works for me. You culd try to figure out what the cpu is doing, if you have access to a hardware- debugger of some kind. > thanks a lot!!!!!! You're welcome. /Daniel >

2 2

[U-Boot-Users] TI1250 PCMCIA + CF
by Rahman, Masoodur 28 Apr '03

28 Apr '03

Hi, I am having a TI 1250 PCI-PCMCIA bridge . I want to boot linux through a Compact Flash Card(PDC202xx) which is sitting across the PCI-PCMCIA bridge. Is it possible to use u-boot to implement the same ? Does u-boot has support for PCMCIA + IDE based CF card ? How does it fall in place in the actual implementation (What are the modules involved ) The board is a IBM750FX based . Thanks a lot .... regards

1 0

[U-Boot-Users] x86 debugger
by Frank 28 Apr '03

28 Apr '03

Can anybody recommend a debugger for u-boot x86 platform... __________________________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo http://search.yahoo.com

2 1

[U-Boot-Users] Porting u-boot to MPC852T
by Paul,Kunal 26 Apr '03

26 Apr '03

hi all, i am porting u-boot to a board having a MPC852T processor.can anyone tell me the essential changes to be made. do we have to make any changes to the mpc8xx directory in the cpu folder??? i understand that it supports all processors of the MPC8xx family. please forward me any patches if anybody has already ported u-boot to MPC852T. regards, kunal

2 1

RE: [U-Boot-Users] AMD MirrorBit FLASH Support?
by Brad Kemp 25 Apr '03

25 Apr '03

There is CFI support for the Intel command set in ppmc8260/strataflash.c and esd/cpic440/strataflash.c. This driver correctly sizes the flash width and number of chips. What is missing is an abstraction to support multiple command sets. Brad > -----Original Message----- > From: Tom Guilliams [mailto:tguilliams@sbs.com] > Sent: Thursday, April 24, 2003 4:38 PM > To: Frederic Soulier > Cc: u-boot-users(a)lists.sourceforge.net > Subject: Re: [U-Boot-Users] AMD MirrorBit FLASH Support? > > > > Thanks for the reply Frederic. > > On Tue, 2003-04-22 at 01:12, Frederic Soulier wrote: > > If you want full support for Mirrorbit flashes in U-Boot, > you have simply to > > code the write buffering feature. > > I do not use this, so standard AMD/Fujitsu/ST code is > working fine for me. > > > > We're finding a bit more to it than that. The algorithms for > operations > on the MirrorBit have changed a bit from other AMD chips. Some > operations rely upon toggle bits, different command definitions. The > "correct" error-checking is what's really effected. I was porting the > StrataFlash driver for the PPMC8260 board because we have > some versions > of our board with StrataFlash and some AMD MirrorBit as well as the > driver implements the CFI interface. > > My plan is to have a strataflash/mirrorbit driver with buffer writing > support. I just need to finish it up and submit it to > Wolfgang. As our > board support grows, I'm adding upon this driver for other chipset > support. At some point, it would be nice to have a flash driver with > CFI for all chips that support it. > > Tom > > > > ------------------------------------------------------- > 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 >

1 0

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

25 Apr '03

Hi all, I compiled u-boot 0.3.0 for the walnut board and run it, it was working fine. Then I replaced the shipped 32MB DIMM module with a 256MB DIMM module with ECC and the board hang: U-Boot 0.3.0 (Apr 25 2003 - 12:10:17) CPU: IBM PowerPC 405GP Rev. E at 200 MHz (PLB=100, OPB=50, EBC=50 MHz) PCI sync clock at 33 MHz, internal PCI arbiter enabled 16 kB I-Cache 8 kB D-Cache Board: WALNUT405-EVB_22 I2C: ready DRAM: 256 MB ***hang*** I examined the function spd_sdram in cpu/ppc4xx/spd_sdram.c and found that the ECC Correction Enable bits in the SDRAM0_ECCCFG register are set to 1 when ECC DIMM is detected. I removed this setting and the board was working without any problems. The 405GP Reference board manual says that using an ECC DIMM on a walnut board, only half of the total DIMM size is available if it is enabled for ECC, but this seems not to work on my board. Has anyone tried out to run the walnut board with ECC DIMM's? What DIMM's did you use? The DIMM I was trying is Infineon HYS72V32220GU (256MB, PC133-222-520). 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

1 0

[U-Boot-Users] DiskOnChip, filesystems, and other booting options
by Udi Finkelstein 25 Apr '03

25 Apr '03

Hello everyone, I've finished porting U-boot 0.3.0 to my MPX823 board. It contains a 512KB 29LV040 that boots u-boot, an extra 8MB DiskOnChip Millenium, and an Ethernet controller (it contains other hardware as well, but that's not relevant). I can now successfully boot the board into Linux by tftp'ing the kernel, and using root nfs (exported NFS is /opt/eldk/ppc_8xx - thanks Worlfgang!). I compiled my own kernel based on the latest linuxppc_2_4 CVS branch. I can successfully access my DiskOnchip under both u-boot and Linux. I now want to boot my board from the on-board Flash. In an ideal world, I would like the DiskOnChip to be: 1. Partition into one or more partitions 2. Boot the kernel from a file in one of the partitions (could be FAT) 3. mount root from separate partition, (if kernel is on FAT), or same partition as the kernel (if possible). I'm slightly confused as to the status of JFFS2, DOS partitioning, DOS FAT/VFAT, and the DiskOnChip support. More specifically: 1. As far as I can tell, the only DiskOnChip support are the "doc read" and "doc write" commands, therefore if I use these commands I must load the kernel directly off the raw sectors - no filesystem support whatsoever. Am I correct? 2. Does the "doc read" and "doc write" use the NFTL layer, or do they access the raw device sectors? 3. As far as I can tell, the FAT support is hardwired to the floppy controller device, and the DOS partition support is wired to the IDE support. Am I right? It seems to me it is quite trivial to construct a simple interface (a struct containing the block device geometry, plus a pointer to sector read function), and have both the partitioning and the DOS FAT code access this. This could help support DOS filesystems on D.O.C, floppies and IDE devices. 4. What is the best way to achieve my requirements above? (booting a kernel from a filesystem on the D.O.C). Can JFFS2 help me in any way? 5. Failing all the above, can I partition the device under Linux into 2 partitions, write down the sector range for the 1st partition, and use it to read/write the kernel using the "doc read" and "doc write interface"? I would then mount the 2nd partition after booting the kernel. thanks, Udi

3 2

[U-Boot-Users] Hi, I am new to U-Boot, how do I get started
by 163 25 Apr '03

25 Apr '03

Hi,I am new to U-Boot,and my cpu is intel xscale pxa250,board is lubbock,how do I get started. Regards weixiong

2 1

Re: [U-Boot-Users] AMD MirrorBit FLASH Support?
by Tom Guilliams 24 Apr '03

24 Apr '03

Thanks for the reply Frederic. On Tue, 2003-04-22 at 01:12, Frederic Soulier wrote: > If you want full support for Mirrorbit flashes in U-Boot, you have simply to > code the write buffering feature. > I do not use this, so standard AMD/Fujitsu/ST code is working fine for me. > We're finding a bit more to it than that. The algorithms for operations on the MirrorBit have changed a bit from other AMD chips. Some operations rely upon toggle bits, different command definitions. The "correct" error-checking is what's really effected. I was porting the StrataFlash driver for the PPMC8260 board because we have some versions of our board with StrataFlash and some AMD MirrorBit as well as the driver implements the CFI interface. My plan is to have a strataflash/mirrorbit driver with buffer writing support. I just need to finish it up and submit it to Wolfgang. As our board support grows, I'm adding upon this driver for other chipset support. At some point, it would be nice to have a flash driver with CFI for all chips that support it. Tom

1 0

[U-Boot-Users] scripting in u-boot
by Paul,Kunal 24 Apr '03

24 Apr '03

hi all, i wanted to know if using scripts is possible in u-boot.if yes how??? where do we store a script file coz we dont have a file system???how to run the script???etc.. regards, kunal

2 1

[U-Boot-Users] new to the u-boot community
by Howard King 23 Apr '03

23 Apr '03

So far I have done the following three things: 1. Donwload the latest version of U-Boot. 2. Have BDI-2000 GDB 3. Join the user mail list community We have a customized 8260 board; like to use u-boot with embedded linux. Can someone point me how to get a quick start? Or point me to the archieve, maybe? Thanks. Howard King

2 1

Re: [U-Boot-Users] Re: Re: mtmsr causes an exception (it was "Problem wi
by llandre 23 Apr '03

23 Apr '03

Thanks to Stefan Roese, I think I definitely solved this bothering problem. It seems the cause is a "hidden" memory access to an invalid location (for example to an address in the SDRAM region before memory controller has been initialized). When stepping through the MTMSR instruction, it seems GDB generates some of these accesses even if the user does not perform a memory read (I suspect such an access is performed to the address contained in the EVPR register). I solved the problem by initializing the SDRAM controller even if the code to be debugged does not need it. This way all accesses to locations ranging from 0x00000000 to 0x08000000 are "well-behaved" and don't cause any exception. llandre

1 0

[U-Boot-Users] New user question(s)
by Eliasson, Anders (IndSys, GEFanuc, VMIC) 23 Apr '03

23 Apr '03

Hello, I'm attempting to build u-boot for the evb64260 brd. I'm doing so on a WinNT4 host with a Cygwin environment and a powerpc-elf cross compiler ( a Linux env is not an option ). This is fun but it's become apparent that I don't know what the heck I'm doing :^). Most of my problems seem to occur as a result of include files missing, in the wrong place, or incorrect. Here's an example of warnings/errors; ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++ make[1]: Entering directory `/cygdrive/d/uboot/uboot030/post/cpu' make[1]: `.depend' is up to date. make[1]: Leaving directory `/cygdrive/d/uboot/uboot030/post/cpu' make[1]: Entering directory `/cygdrive/d/uboot/uboot030/examples' make[1]: `.depend' is up to date. make[1]: Leaving directory `/cygdrive/d/uboot/uboot030/examples' make[1]: Entering directory `/cygdrive/d/uboot/uboot030/tools' gcc -Wall -pedantic -I../include -I.. -DTEXT_BASE=0xfff00000 -DUSE_HOSTCC -O -c -o img2srec.o img2srec.c In file included from img2srec.c:60: ../include/elf.h:67: parse error before `Elf32_Sword' ../include/elf.h:67: warning: type defaults to `int' in declaration of `Elf32_Sw ord' ../include/elf.h:67: ANSI C forbids data definition with no type or storage clas s ../include/elf.h:419: parse error before `Elf32_Sword' ../include/elf.h:419: warning: no semicolon at end of struct or union ../include/elf.h:420: warning: type defaults to `int' in declaration of `Elf32_R ela' ../include/elf.h:420: ANSI C forbids data definition with no type or storage cla ss ../include/elf.h:464: parse error before `Elf32_Sword' ../include/elf.h:464: warning: no semicolon at end of struct or union ../include/elf.h:470: parse error before `}' ../include/elf.h:470: warning: type defaults to `int' in declaration of `Elf32_D yn' ../include/elf.h:470: ANSI C forbids data definition with no type or storage cla ss ../include/elf.h:472: parse error before `_DYNAMIC' ../include/elf.h:472: warning: type defaults to `int' in declaration of `_DYNAMI C' ../include/elf.h:472: ANSI C forbids data definition with no type or storage cla ss In file included from /usr/local/lib/gcc-lib/powerpc-elf/2.95.3/include/unistd.h :4, from img2srec.c:61: /usr/local/lib/gcc-lib/powerpc-elf/2.95.3/include/sys/unistd.h:162: parse error before `ualarm' /usr/local/lib/gcc-lib/powerpc-elf/2.95.3/include/sys/unistd.h:162: parse error before `__useconds' /usr/local/lib/gcc-lib/powerpc-elf/2.95.3/include/sys/unistd.h:162: ANSI C forbi ds data definition with no type or storage class ../include/elf.h:472: warning: array `_DYNAMIC' assumed to have one element make[1]: *** [img2srec.o] Error 1 make[1]: Leaving directory `/cygdrive/d/uboot/uboot030/tools' make: *** [subdirs] Error 1 ---------------------------------------------------------------------------- ---------------------------------------------------- So I'm thinking my Cygwin environment is not set up correctly, or I've missed something else. In any case, has anyone built u-boot in a Win/Cygwin environment, and if so, would you have any suggestions? Any general ideas or suggestions would be appreciated as well. Thanx, Anders VMIC anders.eliasson(a)gefanuc.com

3 2

[U-Boot-Users] Intel IXP4xx support
by Kyle Harris 23 Apr '03

23 Apr '03

Anyone working on a port for the IXP4xx processor? Thanks, Kyle.

1 0

[U-Boot-Users] [PATCH] arp fix, non local subnet error.
by Pantelis Antoniou 22 Apr '03

22 Apr '03

Wolfgang hi. The previous patch, has an ARP problem when the server is not on the same subnet. The following patch, fixes it. Sorry about that. Regards Pantelis --- ../x/u-boot-0.3.0-ping/net/net.c Tue Apr 22 17:07:21 2003 +++ net/net.c Tue Apr 22 17:35:13 2003 @@ -133,6 +133,7 @@ /**********************************************************************/ IPaddr_t NetArpWaitPacketIP; +IPaddr_t NetArpWaitReplyIP; uchar *NetArpWaitPacketMAC; /* MAC address of waiting packet's destination */ uchar *NetArpWaitTxPacket = 0; /* THE transmit packet */ int NetArpWaitTxPacketSize; @@ -170,11 +171,11 @@ if (NetOurGatewayIP == 0) { puts ("## Warning: gatewayip needed but not set\n"); } - NetWriteIP((uchar*)&arp->ar_data[16], NetOurGatewayIP); - } else { - NetWriteIP((uchar*)&arp->ar_data[16], NetArpWaitPacketIP); - } + NetArpWaitReplyIP = NetOurGatewayIP; + } else + NetArpWaitReplyIP = NetArpWaitPacketIP; + NetWriteIP((uchar*)&arp->ar_data[16], NetArpWaitReplyIP); (void) eth_send(NetTxPacket, ETHER_HDR_SIZE + ARP_HDR_SIZE); } @@ -716,7 +717,7 @@ tmp = NetReadIP(&arp->ar_data[6]); /* matched waiting packet's address */ - if (tmp == NetArpWaitPacketIP) { + if (tmp == NetArpWaitReplyIP) { #ifdef ET_DEBUG printf("Got it\n"); #endif

1 0

Fw: [U-Boot-Users] AMD MirrorBit FLASH Support?
by Frederic Soulier 22 Apr '03

22 Apr '03

Hi there, We use AMD and Fujitsu mirrorbit Flash chips on our custom board. It works fine with U-Boot since Mirrorbit flash command operations are the same as classical AMD parts. However few specifications change between classical and mirrorbit flashes : - Programming time is 100us with mirrorbit (16 us for classical), and because of this : - Mirrorbit allow to write several words in one command (write buffer programming) If you want full support for Mirrorbit flashes in U-Boot, you have simply to code the write buffering feature. I do not use this, so standard AMD/Fujitsu/ST code is working fine for me. Frederic Soulier OS engineer Audemat-Aztec, Strasbourg, France > ----- Original Message ----- > From: "Tom Guilliams" <tguilliams(a)sbs.com> > To: <u-boot-users(a)lists.sourceforge.net> > Sent: Tuesday, April 22, 2003 1:22 AM > Subject: [U-Boot-Users] AMD MirrorBit FLASH Support? > > > > Does anyone know of support for the AMD MirrorBit FLASH parts? For > example, > > the AM29LV256M - 256MB, x8/x16 data width. There's really not much to > > change compared to strataflash but I thought I'd ask in case someone's > > already done it. I don't see anything in the source tree but I could be > > wrong. > > > > - Tom > > > > > > ------------------------------------------------------- > > 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 > > >

1 0

[U-Boot-Users] [PATCH] ARP/TFTP disengagement.
by Pantelis Antoniou 22 Apr '03

22 Apr '03

Wolfang Hi. In U-boot currently ARP is use for the single purpose, of providing the MAC address of the TFTP server. This make it impossible to use ARP for communicating with any other host or protocol. Also it muddles the tftp code since in order to begin the TFTP request, we don't call TftpStart rather we call ArpRequest and the tftp request is started explicitly upon reception of the ARP reply. The following patch fixes these problems. Instead of the TFTP code using NetSendPacket it uses now a new function called NetSendUDPPacket. int NetSendUDPPacket(uchar *ether, IPaddr_t dest, int dport, int sport, int len); The argument are as follows; uchar *ether - pointer to MAC address of the server/or gateway. If the MAC address is zero, an ARP request is made and the packet is saved for transmition upon the reception of the ARP reply. Must point to a global or static variable for proper operation. IPaddr_t dest - destination ip address int dport - destination port int sport - source port int len - the length of the data. The actual contents of the transmitted packet are expected to be at NetTxPacket + ETHER_HDR_SIZE + IP_HDR_SIZE. The major change of this patch is the elimination of the files arp.c & arp.h. ARP is not really a proper protocol, and their functionality is placed directly in net.c Tested both in manual tftp mode and DHCP auto-start mode... Awaiting comments... Regards Pantelis diff -ruNb u-boot-0.3.0-orig/include/net.h u-boot-0.3.0/include/net.h --- u-boot-0.3.0-orig/include/net.h Mon Apr 21 10:10:04 2003 +++ u-boot-0.3.0/include/net.h Tue Apr 22 12:37:48 2003 @@ -326,6 +326,9 @@ /* Transmit "NetTxPacket" */ extern void NetSendPacket(volatile uchar *, int); +/* Transmit UDP packet, performing ARP request if needed */ +extern int NetSendUDPPacket(uchar *ether, IPaddr_t dest, int dport, int sport, int len); + /* Processes a received packet */ extern void NetReceive(volatile uchar *, int); diff -ruNb u-boot-0.3.0-orig/net/Makefile u-boot-0.3.0/net/Makefile --- u-boot-0.3.0-orig/net/Makefile Mon Apr 21 10:10:04 2003 +++ u-boot-0.3.0/net/Makefile Tue Apr 22 12:32:44 2003 @@ -27,7 +27,7 @@ LIB = libnet.a -OBJS = net.o tftp.o bootp.o rarp.o arp.o eth.o +OBJS = net.o tftp.o bootp.o rarp.o eth.o all: $(LIB) $(LIB): $(START) $(OBJS) diff -ruNb u-boot-0.3.0-orig/net/arp.c u-boot-0.3.0/net/arp.c --- u-boot-0.3.0-orig/net/arp.c Mon Apr 21 10:10:04 2003 +++ u-boot-0.3.0/net/arp.c Thu Jan 1 02:00:00 1970 @@ -1,120 +0,0 @@ -/* - * (C) Copyright 2000 - * Wolfgang Denk, DENX Software Engineering, wd(a)denx.de. - * - * See file CREDITS for list of people who contributed to this - * project. - * - * This program is free software; you can redistribute it and/or - * modify it under the terms of the GNU General Public License as - * published by the Free Software Foundation; either version 2 of - * the License, or (at your option) any later version. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, - * MA 02111-1307 USA - */ - -#include <common.h> -#include <command.h> -#include <net.h> -#include "bootp.h" -#include "tftp.h" -#include "arp.h" - -#if (CONFIG_COMMANDS & CFG_CMD_NET) - -#define TIMEOUT 5 /* Seconds before trying ARP again */ -#ifndef CONFIG_NET_RETRY_COUNT -# define TIMEOUT_COUNT 5 /* # of timeouts before giving up */ -#else -# define TIMEOUT_COUNT (CONFIG_NET_RETRY_COUNT) -#endif - -static void ArpHandler(uchar *pkt, unsigned dest, unsigned src, unsigned len); -static void ArpTimeout(void); - -int ArpTry = 0; - -/* - * Handle a ARP received packet. - */ -static void -ArpHandler(uchar *pkt, unsigned dest, unsigned src, unsigned len) -{ - /* Check if the frame is really an ARP reply */ - if (memcmp (NetServerEther, NetBcastAddr, 6) != 0) { -#ifdef DEBUG - printf("Got good ARP - start TFTP\n"); -#endif - TftpStart (); - } -} - - -/* - * Timeout on ARP request. - */ -static void -ArpTimeout(void) -{ - if (ArpTry >= TIMEOUT_COUNT) { - puts ("\nRetry count exceeded; starting again\n"); - NetStartAgain (); - } else { - NetSetTimeout (TIMEOUT * CFG_HZ, ArpTimeout); - ArpRequest (); - } -} - - -void -ArpRequest (void) -{ - int i; - volatile uchar *pkt; - ARP_t * arp; - - printf("ARP broadcast %d\n", ++ArpTry); - pkt = NetTxPacket; - - NetSetEther(pkt, NetBcastAddr, PROT_ARP); - pkt += ETHER_HDR_SIZE; - - arp = (ARP_t *)pkt; - - arp->ar_hrd = htons(ARP_ETHER); - arp->ar_pro = htons(PROT_IP); - arp->ar_hln = 6; - arp->ar_pln = 4; - arp->ar_op = htons(ARPOP_REQUEST); - - memcpy (&arp->ar_data[0], NetOurEther, 6); /* source ET addr */ - NetWriteIP((uchar*)&arp->ar_data[6], NetOurIP); /* source IP addr */ - for (i=10; i<16; ++i) { - arp->ar_data[i] = 0; /* dest ET addr = 0 */ - } - - if((NetServerIP & NetOurSubnetMask) != (NetOurIP & NetOurSubnetMask)) { - if (NetOurGatewayIP == 0) { - puts ("## Warning: gatewayip needed but not set\n"); - } - NetWriteIP((uchar*)&arp->ar_data[16], NetOurGatewayIP); - } else { - NetWriteIP((uchar*)&arp->ar_data[16], NetServerIP); - } - - - NetSendPacket(NetTxPacket, ETHER_HDR_SIZE + ARP_HDR_SIZE); - - NetSetTimeout(TIMEOUT * CFG_HZ, ArpTimeout); - NetSetHandler(ArpHandler); -} - -#endif /* CFG_CMD_NET */ diff -ruNb u-boot-0.3.0-orig/net/arp.h u-boot-0.3.0/net/arp.h --- u-boot-0.3.0-orig/net/arp.h Mon Apr 21 10:10:04 2003 +++ u-boot-0.3.0/net/arp.h Thu Jan 1 02:00:00 1970 @@ -1,40 +0,0 @@ -/* - * (C) Copyright 2000 - * Wolfgang Denk, DENX Software Engineering, wd(a)denx.de. - * - * See file CREDITS for list of people who contributed to this - * project. - * - * This program is free software; you can redistribute it and/or - * modify it under the terms of the GNU General Public License as - * published by the Free Software Foundation; either version 2 of - * the License, or (at your option) any later version. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, - * MA 02111-1307 USA - */ - - -#ifndef __ARP_H__ -#define __ARP_H__ - -/**********************************************************************/ -/* - * Global functions and variables. - */ - -extern int ArpTry; - -extern void ArpRequest (void); /* Send a ARP request */ - -/**********************************************************************/ - -#endif /* __ARP_H__ */ - diff -ruNb u-boot-0.3.0-orig/net/bootp.c u-boot-0.3.0/net/bootp.c --- u-boot-0.3.0-orig/net/bootp.c Mon Apr 21 10:10:04 2003 +++ u-boot-0.3.0/net/bootp.c Tue Apr 22 12:32:45 2003 @@ -24,7 +24,6 @@ #include <net.h> #include "bootp.h" #include "tftp.h" -#include "arp.h" #ifdef CONFIG_STATUS_LED #include <status_led.h> #endif @@ -335,10 +334,7 @@ return; } - /* Send ARP request to get TFTP server ethernet address. - * This automagically starts TFTP, too. - */ - ArpRequest(); + TftpStart(); } #endif /* !CFG_CMD_DHCP */ @@ -866,10 +862,7 @@ NetState = NETLOOP_SUCCESS; return; } - /* Send ARP request to get TFTP server ethernet address. - * This automagically starts TFTP, too. - */ - ArpRequest(); + TftpStart(); return; } break; diff -ruNb u-boot-0.3.0-orig/net/net.c u-boot-0.3.0/net/net.c --- u-boot-0.3.0-orig/net/net.c Mon Apr 21 10:10:04 2003 +++ u-boot-0.3.0/net/net.c Tue Apr 22 12:32:45 2003 @@ -65,10 +65,16 @@ #include "bootp.h" #include "tftp.h" #include "rarp.h" -#include "arp.h" #if (CONFIG_COMMANDS & CFG_CMD_NET) +#define ARP_TIMEOUT 5 /* Seconds before trying ARP again */ +#ifndef CONFIG_NET_RETRY_COUNT +# define ARP_TIMEOUT_COUNT 5 /* # of timeouts before giving up */ +#else +# define ARP_TIMEOUT_COUNT (CONFIG_NET_RETRY_COUNT) +#endif + #if 0 #define ET_DEBUG #endif @@ -88,7 +94,7 @@ ulong NetBootFileXferSize; /* The actual transferred size of the bootfile (in bytes) */ uchar NetOurEther[6]; /* Our ethernet address */ uchar NetServerEther[6] = /* Boot server enet address */ - { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff }; + { 0, 0, 0, 0, 0, 0 }; IPaddr_t NetOurIP; /* Our IP addr (0 = unknown) */ IPaddr_t NetServerIP; /* Our IP addr (0 = unknown) */ volatile uchar *NetRxPkt; /* Current receive packet */ @@ -96,6 +102,8 @@ unsigned NetIPID; /* IP packet ID */ uchar NetBcastAddr[6] = /* Ethernet bcast address */ { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff }; +uchar NetEtherNullAddr[6] = + { 0, 0, 0, 0, 0, 0 }; int NetState; /* Network loop state */ #ifdef CONFIG_NET_MULTI int NetRestartWrap = 0; /* Tried all network devices */ @@ -117,6 +125,78 @@ static int net_check_prereq (proto_t protocol); /**********************************************************************/ + +IPaddr_t NetArpWaitPacketIP; +uchar *NetArpWaitPacketMAC; /* MAC address of waiting packet's destination */ +uchar *NetArpWaitTxPacket = 0; /* THE transmit packet */ +int NetArpWaitTxPacketSize; +uchar NetArpWaitPacketBuf[PKTSIZE_ALIGN + PKTALIGN]; +ulong NetArpWaitTimerStart; +int NetArpWaitTry; + +void ArpRequest(void) +{ + int i; + volatile uchar *pkt; + ARP_t * arp; + + printf("ARP broadcast %d\n", NetArpWaitTry); + pkt = NetTxPacket; + + NetSetEther(pkt, NetBcastAddr, PROT_ARP); + pkt += ETHER_HDR_SIZE; + + arp = (ARP_t *)pkt; + + arp->ar_hrd = htons(ARP_ETHER); + arp->ar_pro = htons(PROT_IP); + arp->ar_hln = 6; + arp->ar_pln = 4; + arp->ar_op = htons(ARPOP_REQUEST); + + memcpy (&arp->ar_data[0], NetOurEther, 6); /* source ET addr */ + NetWriteIP((uchar*)&arp->ar_data[6], NetOurIP); /* source IP addr */ + for (i=10; i<16; ++i) { + arp->ar_data[i] = 0; /* dest ET addr = 0 */ + } + + if((NetArpWaitPacketIP & NetOurSubnetMask) != (NetOurIP & NetOurSubnetMask)) { + if (NetOurGatewayIP == 0) { + puts ("## Warning: gatewayip needed but not set\n"); + } + NetWriteIP((uchar*)&arp->ar_data[16], NetOurGatewayIP); + } else { + NetWriteIP((uchar*)&arp->ar_data[16], NetArpWaitPacketIP); + } + + (void) eth_send(NetTxPacket, ETHER_HDR_SIZE + ARP_HDR_SIZE); +} + +void ArpTimeoutCheck(void) +{ + ulong t; + + if (!NetArpWaitPacketIP) + return; + + t = get_timer(0); + + /* check for arp timeout */ + if ((t - NetArpWaitTimerStart) > ARP_TIMEOUT * CFG_HZ) { + NetArpWaitTry++; + + if (NetArpWaitTry >= ARP_TIMEOUT_COUNT) { + puts ("\nARP Retry count exceeded; starting again\n"); + NetArpWaitTry = 0; + NetStartAgain(); + } else { + NetArpWaitTimerStart = t; + ArpRequest(); + } + } +} + +/**********************************************************************/ /* * Main network processing loop. */ @@ -144,6 +224,13 @@ for (i = 0; i < PKTBUFSRX; i++) { NetRxPackets[i] = NetTxPacket + (i+1)*PKTSIZE_ALIGN; } + + } + + if (!NetArpWaitTxPacket) { + NetArpWaitTxPacket = &NetArpWaitPacketBuf[0] + (PKTALIGN - 1); + NetArpWaitTxPacket -= (ulong)NetArpWaitTxPacket % PKTALIGN; + NetArpWaitTxPacketSize = 0; } eth_halt(); @@ -202,8 +289,7 @@ switch (protocol) { case TFTP: /* always use ARP to get server ethernet address */ - ArpTry = 0; - ArpRequest (); + TftpStart(); break; #if (CONFIG_COMMANDS & CFG_CMD_DHCP) @@ -260,6 +346,7 @@ return (-1); } + ArpTimeoutCheck(); /* * Check for a timeout, and run the timeout handler @@ -376,7 +463,44 @@ (void) eth_send(pkt, len); } +int +NetSendUDPPacket(uchar *ether, IPaddr_t dest, int dport, int sport, int len) +{ + /* if MAC address was not discovered yet, save the packet and do an ARP request */ + if (memcmp(ether, NetEtherNullAddr, 6) == 0) { + +#ifdef ET_DEBUG + printf("sending ARP for %08lx\n", dest); +#endif + + NetArpWaitPacketIP = dest; + NetArpWaitPacketMAC = ether; + NetSetEther (NetArpWaitTxPacket, NetArpWaitPacketMAC, PROT_IP); + NetSetIP (NetArpWaitTxPacket + ETHER_HDR_SIZE, dest, dport, sport, len); + memcpy(NetArpWaitTxPacket + ETHER_HDR_SIZE + IP_HDR_SIZE, + (uchar *)NetTxPacket + ETHER_HDR_SIZE + IP_HDR_SIZE, len); + + /* size of the waiting packet */ + NetArpWaitTxPacketSize = ETHER_HDR_SIZE + IP_HDR_SIZE + len; + + /* and do the ARP request */ + NetArpWaitTry = 1; + NetArpWaitTimerStart = get_timer(0); + ArpRequest(); + return 1; /* waiting */ + } + +#ifdef ET_DEBUG + printf("sending UDP to %08lx/%02x:%02x:%02x:%02x:%02x:%02x\n", + dest, ether[0], ether[1], ether[2], ether[3], ether[4], ether[5]); +#endif + NetSetEther (NetTxPacket, ether, PROT_IP); + NetSetIP (NetTxPacket + ETHER_HDR_SIZE, dest, dport, sport, len); + (void) eth_send(NetTxPacket, ETHER_HDR_SIZE + IP_HDR_SIZE + len); + + return 0; /* transmited */ +} void NetReceive(volatile uchar * pkt, int len) @@ -462,14 +586,40 @@ NetCopyIP(&arp->ar_data[16], &arp->ar_data[6]); memcpy (&arp->ar_data[ 0], NetOurEther, 6); NetCopyIP(&arp->ar_data[ 6], &NetOurIP); - NetSendPacket((uchar *)et,((uchar *)arp-pkt)+ARP_HDR_SIZE); + (void) eth_send((uchar *)et, ((uchar *)arp-pkt) + ARP_HDR_SIZE); return; - case ARPOP_REPLY: /* set TFTP server eth addr */ + + case ARPOP_REPLY: /* arp reply */ + /* are we waiting for a reply */ + if (!NetArpWaitPacketIP) + break; #ifdef ET_DEBUG - printf("Got ARP REPLY, set server/gtwy eth addr\n"); + printf("Got ARP REPLY, set server/gtwy eth addr (%02x:%02x:%02x:%02x:%02x:%02x)\n", + arp->ar_data[0], arp->ar_data[1], + arp->ar_data[2], arp->ar_data[3], + arp->ar_data[4], arp->ar_data[5]); #endif - memcpy (NetServerEther, &arp->ar_data[0], 6); - (*packetHandler)(0,0,0,0); /* start TFTP */ + + tmp = NetReadIP(&arp->ar_data[6]); + + /* matched waiting packet's address */ + if (tmp == NetArpWaitPacketIP) { +#ifdef ET_DEBUG + printf("Got it\n"); +#endif + /* save address for later use */ + memcpy(NetArpWaitPacketMAC, &arp->ar_data[0], 6); + + /* modify header, and transmit it */ + memcpy(((Ethernet_t *)NetArpWaitTxPacket)->et_dest, NetArpWaitPacketMAC, 6); + (void) eth_send(NetArpWaitTxPacket, NetArpWaitTxPacketSize); + + /* no arp request pending now */ + NetArpWaitPacketIP = 0; + NetArpWaitTxPacketSize = 0; + NetArpWaitPacketMAC = NULL; + + } return; default: #ifdef ET_DEBUG diff -ruNb u-boot-0.3.0-orig/net/tftp.c u-boot-0.3.0/net/tftp.c --- u-boot-0.3.0-orig/net/tftp.c Mon Apr 21 10:10:04 2003 +++ u-boot-0.3.0/net/tftp.c Tue Apr 22 12:40:41 2003 @@ -142,10 +142,7 @@ break; } - NetSetEther (NetTxPacket, NetServerEther, PROT_IP); - NetSetIP (NetTxPacket + ETHER_HDR_SIZE, NetServerIP, - TftpServerPort, TftpOurPort, len); - NetSendPacket (NetTxPacket, ETHER_HDR_SIZE + IP_HDR_SIZE + len); + NetSendUDPPacket(NetServerEther, NetServerIP, TftpServerPort, TftpOurPort, len); } @@ -257,17 +254,6 @@ void TftpStart (void) { -#ifdef ET_DEBUG - printf ("\nServer ethernet address %02x:%02x:%02x:%02x:%02x:%02x\n", - NetServerEther[0], - NetServerEther[1], - NetServerEther[2], - NetServerEther[3], - NetServerEther[4], - NetServerEther[5] - ); -#endif /* DEBUG */ - if (BootFile[0] == '\0') { IPaddr_t OurIP = ntohl(NetOurIP);

1 0

[U-Boot-Users] AMD MirrorBit FLASH Support?
by Tom Guilliams 22 Apr '03

22 Apr '03

Does anyone know of support for the AMD MirrorBit FLASH parts? For example, the AM29LV256M - 256MB, x8/x16 data width. There's really not much to change compared to strataflash but I thought I'd ask in case someone's already done it. I don't see anything in the source tree but I could be wrong. - Tom

2 1

[U-Boot-Users] start / load addresses for kernel
by Jerry Walden 21 Apr '03

21 Apr '03

Hello: I received the below advice recently: >since you are building for a non openbios kernel, you will need >to change the make file. The start/ load addresses and all are different I am trying to get more detail on what needs to change, I see 2 config options: 1) CONFIG_KERNEL_START_BOOL - is set this to yes 2) CONFIG_KERNEL_START -- what should this be set to - the default is 0xc0000000 seems fine to me Are there any other options that I am missing? Below is a log of my attempt to boot the kernel - displayed are the command line that is getting passed in, and well as the startup parameters - do these look okay - I made sure that the kernel bd_info struct is the same as the u-boot struct **************************************************************************** Script started on Fri Mar 21 14:43:27 2003 Welcome to minicom 1.83.1 U-Boot 0.2.0 (Mar 19 2003 - 12:09:59) CPU: IBM PowerPC 405GPr Rev. A at 266.666 MHz (PLB=133, OPB=66, EBC=26 MHz) PCI async ext clock used, internal PCI arbiter enabled 16 kB I-Cache 16 kB D-Cache Board: ### No HW ID - assuming WALNUT405 I2C: ready DRAM: 64 MB Now running in RAM - U-Boot at: 03fcf000 FLASH: 512 kB *** Warning - bad CRC, using default environment PCI: Bus Dev VenId DevId Class Int PCI Autoconfig: Memory region: [20000000-27ffffff] PCI Autoconfig: I/O region: [800000-3ffffff] PCI Scan: Found Bus 0, Device 0, Function 0 PCI Scan: Found Bus 0, Device 7, Function 0 PCI Autoconfig: BAR 0, Mem, size=0x1000000, address=0x20000000 PCI Autoconfig: BAR 1, I/O, size=0xffffff04, No room in resource PCI Autoconfig: BAR 2, I/O, size=0x1000000, address=0x1000000 00 07 1394 0978 0200 1c In: serial Out: serial Err: serial U-Boot relocated to 03fcf000 IDE: Bus 0: port = c OK Device 0: Model: SanDisk SDCFB-64 Firm: Vdg 8.16. Ser#: 111913G1602X4714 Type: Removable Hard Disk Capacity: 61.2 MB = 0.0 GB (125440 x 512) => => imi 0x200000 ## Checking Image at 00200000 ... Image Name: Linux-2.4.18_mvl30-walnut Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 298601 Bytes = 291.6 kB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK => bootm 0x200000 ## Booting image at 00200000 ... Image Name: Linux-2.4.18_mvl30-walnut Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 298601 Bytes = 291.6 kB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Uncompressing Kernel Image ... OK ## Current stack ends at 0x03F9EBD8 => set upper limit to 0x00800000 ## cmdline at 0x007FFF00 ... 0x007FFF20 root=/dev/ram console=ttyS0,9600 memsize = 0x04000000 flashstart = 0xFFF80000 flashsize = 0x00080000 flashoffset = 0x00031000 sramstart = 0x00000000 sramsize = 0x00000000 bootflags = 0x001E8480 procfreq = 266.666 MHz plb_busfreq = 133.333 MHz pci_busfreq = 33.333 MHz ethaddr = 00:00:00:00:00:00 IP addr = 0.0.0.0 baudrate = 9600 bps No initrd ## Transferring control to Linux (at address 00000000) ... Thanks Jerry Walden

8 25

[U-Boot-Users] porting u-boot on MPC852T
by lixi_avansys 21 Apr '03

21 Apr '03

hi All, I want to using u-boot on MPC852T(Motorola 's new low cost PowerPC processor),is anybody have done this porting? if nobody have done this,how about the workload to porting it. thanks a lot. windstone

2 1

[U-Boot-Users] porting on MPC852T
by lixi_avansys 21 Apr '03

21 Apr '03

hi All, I want to using ppcboot on MPC852T(Motorola 's new low cost PowerPC processor),is anybody have done this porting? if nobody have done this,how about the workload to porting it. thanks a lot.

1 0

[U-Boot-Users] u-boot errors
by invictus rm 20 Apr '03

20 Apr '03

hi, While compiling u-boot for the LART board , i am getting the following errors from the version checked out from CVS make lart_config make /home/rm/u-boot/include/asm/io.h:25: asm/memory.h: No such file or directory On adding the file from linux kernel sources (memory.h), it proceeds but stops at another place. cpu/sa1100/libsa1100.a(interrupts.o): In function `show_regs': /home/rm/arm_linux/u-boot/cpu/sa1100/interrupts.c:115: undefined reference to `thumb_mode' /home/rm/arm_linux/u-boot/cpu/sa1100/interrupts.c:115: relocation truncated to fit: R_ARM_PC24 thumb_mode make: *** [u-boot] Error 1 although interrupts.c has ptrace.h included Am i missing something ? rgds rm _________________________________________________________________ Windows Server 2003. Do more with less. http://www.msn.co.in/computing/winsvr2003/ Upgrade now!

1 0

[U-Boot-Users] Code compatibility 750 to 7410
by Roel Loeffen 17 Apr '03

17 Apr '03

Simple question I guess: Can code build for a MPC750 run on a MPC7410 without any changes or recompilation? Thx Roel ---------------------------- Prodrive B.V. Postbus 28030 5602 JA Eindhoven The Netherlands ---------------------------- Science Park Eindhoven Ekkersrijt 5025 5692 EB Son ---------------------------- tel. +31 40 2676200 direct: +31 40 2676242 fax +31 40 2676220 ----------------------------

2 1

[U-Boot-Users] RTEMS patch
by Erwin Rol 17 Apr '03

17 Apr '03

I saw a patch to boot ARTOS with U-boot, and noticed that my RTEMS patch didn't make it into 0.3.0. (it also doesn't show up in the SourceForge CVS ). Is there a reason for this, or did it just got lost some where ? - Erwin -- Dipl.-Ing. Erwin Rol - Software Engineering tel: +49-(0)8024-479377 gsm: +49-(0)171-6929198 fax: +49-(0)8024-479379 email: erwin(a)muffin.org

2 2

[U-Boot-Users] IVT on 405GP
by Jerry Walden 16 Apr '03

16 Apr '03

Greetings: If someone out there has a 405GP running with u-boot, I'd really appreciated a snapshot of the interrupt vector table. It appears that though the vector and and the int return vector are getting copied, however if prior to running u-boot I zero out all memory in the IVT, I see that not Prologue code etc is getting coping into those ares. If I look at "trap_init" it appears as though it does not copy code, and only sets vectors. If I look at "relocate_code" it appears as though it only starts to copy code from the top of the boot rom to the end. I do not see where the interrupt vectors are stored in the bootrom - although they must - so I must be missing a simple calculation someplace - Any assistance is greatly appreciated. Jerry Walden

5 8

[U-Boot-Users] Ebony boot issues -- help wanted
by Jeff H Zhong 16 Apr '03

16 Apr '03

Thanks for the reminder from Wolfgang. I tried to send my first post to this list in html format and got failed. Now I redo my post and hope to get some help from you. Hi Guys, I am new to both this mailing-list and embedded linuxppc. Currently I am working on IBM ebony evaluation platform, and I got couple of doubts which I can't figure out. I programmed u-boot 3.0.0 into the flash and trying to use NFS to boot the kernel. Here are my questions, 1. At U-Boot phase I got output on console: U-Boot 0.3.0 (Apr 15 2003 - 14:12:33) IBM PowerPC 440 Rev. C Board: IBM 440GP Evaluation Board (Ebony) VCO: 800 MHz CPU: 400 MHz PLB: 133 MHz OPB: 66 MHz EPB: 66 MHz I2C: ready DRAM: I2c read: failed 4 I2c read: failed 4 128 MB FLASH: 4.5 MB PCI: Bus Dev VenId DevId Class Int 00 04 1095 0680 0104 00 In: serial Out: serial Err: serial KGDB: kgdb ready ready BEDBUG:ready => Why u-boot failed on my DRAM I2C read although it still can find out the correctly amount ? At this point of time, I am not able to ping the target from my host(RH 7.3). From the host: root@Jeff u-boot-0.3.0<1063>ping 7.1.1.6 PING 7.1.1.6 (7.1.1.6) from 7.1.1.4 : 56(84) bytes of data. >From 7.1.1.4 icmp_seq=1 Destination Host Unreachable >From 7.1.1.4 icmp_seq=2 Destination Host Unreachable .... root@Jeff u-boot-0.3.0<1064>cat /proc/net/arp IP address HW type Flags HW address Mask Device 7.1.1.6 0x1 0x0 00:00:00:00:00:00 * eth1 10.1.1.171 0x1 0x2 00:A0:C5:E0:C4:EC * eth0 I guess that dear Ms. U-Boot does not bring up arp, is that correct? 2. Now, I am trying to tftp kernel image, and on target console: => tftp ENET Speed is 100 Mbps - FULL duplex connection ARP broadcast 1 TFTP from server 7.1.1.4; our IP address is 7.1.1.6 Filename 'vmlinux.PPCBoot'. Load address: 0x1000000 Loading: ################################################################# ################################################################# ########### done Bytes transferred = 718502 (af6a6 hex) => Ok, she got the image. On host side, I have: root@Jeff u-boot-0.3.0<1065>cat /proc/net/arp IP address HW type Flags HW address Mask Device 7.1.1.6 0x1 0x0 00:04:AC:E3:1D:62 * eth1 10.1.1.171 0x1 0x2 00:A0:C5:E0:C4:EC * eth0 Ms. U-Boot looks more pretty and coorprative now, right? But I still couldn't ping her, root@Jeff u-boot-0.3.0<1066>ping 7.1.1.6 PING 7.1.1.6 (7.1.1.6) from 7.1.1.4 : 56(84) bytes of data. >From 7.1.1.4 icmp_seq=1 Destination Host Unreachable >From 7.1.1.4 icmp_seq=2 Destination Host Unreachable ...... 3. Now I am trying to boot up kernel, she says: => bootm ## Booting image at 01000000 ... Image Name: Linux-2.4.21-pre7-big Created: 2003-04-15 18:05:48 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 718438 Bytes = 701.6 kB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Uncompressing Kernel Image ... OK Linux version 2.4.21-pre7-big (root@Jeff) (gcc version 2.95.2 19991024 (release) ) #60 Tue Apr 15 18:04:53 UTC 2003 IBM Ebony port (C) 2002 MontaVista Software, Inc. (source(a)mvista.com) On node 0 totalpages: 32768 zone(0): 4096 pages. zone(1): 28672 pages. zone(2): 0 pages. Kernel command line: console=ttyS0,9600 ip=7.1.1.6:::255.255.255.0:ppclinux:eth0 nfsroot=7.1.1.4:/exports/eldk/ppc_4xx Calibrating delay loop... 599.65 BogoMIPS Memory: 127436k available (1176k kernel code, 420k data, 224k init, 0k highmem) Dentry cache hash table entries: 16384 (order: 5, 131072 bytes) Inode cache hash table entries: 8192 (order: 4, 65536 bytes) Mount cache hash table entries: 512 (order: 0, 4096 bytes) Buffer-cache hash table entries: 8192 (order: 3, 32768 bytes) Page-cache hash table entries: 32768 (order: 5, 131072 bytes) POSIX conformance testing by UNIFIX PCI: Probing PCI hardware Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket Starting kswapd devfs: v1.12c (20020818) Richard Gooch (rgooch(a)atnf.csiro.au) devfs: boot_options: 0x1 Installing knfsd (copyright (C) 1996 okir(a)monad.swb.de). i2c-core.o: i2c core module i2c-dev.o: i2c /dev entries driver module i2c-core.o: driver i2c-dev dummy driver registered. i2c-proc.o version 2.6.1 (20010825) pty: 256 Unix98 ptys configured Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI en abled ttyS00 at 0xfdfe9200 (irq = 0) is a 16550A ttyS01 at 0xfdfe8300 (irq = 1) is a 16550A RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize Zmii bridge in RMII mode eth0: Phy @ 0x8, type Am79c875A (0x00225541) Reset ethernet interfaces Zmii bridge in RMII mode eth1: Phy @ 0x9, type Am79c875A (0x00225541) Reset ethernet interfaces Uniform Multi-Platform E-IDE driver Revision: 7.00beta-2.4 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx SiI680: IDE controller at PCI slot 00:04.0 SiI680: chipset revision 1 SiI680: not 100% native mode: will probe irqs later SiI680: BASE CLOCK == 133 ide0: MMIO-DMA at 0xc900ef00-0xc900ef07, BIOS settings: hda:pio, hdb:pio ide1: MMIO-DMA at 0xc900ef08-0xc900ef0f, BIOS settings: hdc:pio, hdd:pio Probing IDE interface ide0... hda: IBM-DTLA-307015, ATA DISK drive blk: queue c01c10d0, I/O limit 4095Mb (mask 0xffffffff) Probing IDE interface ide1... ide0 at 0xc900ef80-0xc900ef87,0xc900ef8a on irq 26 hda: attached ide-disk driver. hda: host protected area => 1 hda: 30003120 sectors (15362 MB) w/1916KiB Cache, CHS=29765/16/63, UDMA(100) Partition check: /dev/ide/host0/bus0/target0/lun0: [PTBL] [1867/255/63] p1 IBM IIC driver i2c-dev.o: Registered 'IBM IIC adapter' as minor 0 i2c-core.o: adapter IBM IIC adapter registered as adapter 0. i2c-dev.o: Registered 'IBM IIC adapter' as minor 1 i2c-core.o: adapter IBM IIC adapter registered as adapter 1. NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP IP: routing cache hash table of 1024 buckets, 8Kbytes TCP: Hash tables configured (established 8192 bind 8192) eth0: IBM EMAC: link up, 100 Mbps Full Duplex, auto-negotiation complete. eth0: IBM EMAC: MAC ff:ff:ff:ff:ff:ff. eth0: IBM EMAC: open completed IP-Config: Complete: device=eth0, addr=7.1.1.6, mask=255.255.255.0, gw=255.255.255.255, host=ppclinux, domain=, nis-domain=(none), bootserver=255.255.255.255, rootserver=7.1.1.4, rootpath= NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. Looking up port of RPC 100003/2 on 7.1.1.4 Look, Mrs. U-Boot bring up the kernel and Mr. Kernel talks lot but he stucks here refusing to move ahead. Seems like kernel didn't get his MAC address properly, so he couldn't connect to host bootp server. My question is that how does Ms. U-Boot pass the environment variable to Mr. Kernel, as something I got from this archive? On host: root@Jeff u-boot-0.3.0<1067>cat /proc/net/arp IP address HW type Flags HW address Mask Device 7.1.1.6 0x1 0x0 00:04:AC:E3:1D:62 * eth1 10.1.1.171 0x1 0x2 00:A0:C5:E0:C4:EC * eth0 4. Then I issued a ping from host, root@Jeff u-boot-0.3.0<1068>ping 7.1.1.6 PING 7.1.1.6 (7.1.1.6) from 7.1.1.4 : 56(84) bytes of data. 64 bytes from 7.1.1.6: icmp_seq=1 ttl=64 time=0.506 ms 64 bytes from 7.1.1.6: icmp_seq=2 ttl=64 time=0.166 ms 64 bytes from 7.1.1.6: icmp_seq=3 ttl=64 time=0.146 ms 64 bytes from 7.1.1.6: icmp_seq=4 ttl=64 time=0.137 ms 64 bytes from 7.1.1.6: icmp_seq=5 ttl=64 time=0.138 ms 64 bytes from 7.1.1.6: icmp_seq=6 ttl=64 time=0.137 ms ..... This makes Mr. Kernel keep going: Looking up port of RPC 100005/1 on 7.1.1.4 VFS: Mounted root (nfs filesystem). Mounted devfs on /dev Freeing unused kernel memory: 224k init INIT: version 2.78 booting Remounting the root filesystem read-write. Cleaning: /tmp /var/lock /var/run. Mounting local file systems... none on /dev/pts type devpts (rw,gid=5,mode=620) Setting up IP spoofing protection: rp_filter. Configuring network interfaces: done. Starting portmap daemon: portmap. Initializing random number generator... done. INIT: Entering runlevel: 2 Starting system logger: Done Starting kernel logger: Done Starting xinetd: Done Welcome to DoReMi Labs. Inc. ppclinux login: Looks like the kernel got himself's MAC through the icmp message. It is fairly wired to me. At this moment, on host: root@Jeff u-boot-0.3.0<1069>cat /proc/net/arp IP address HW type Flags HW address Mask Device 7.1.1.6 0x1 0x2 FF:FF:FF:FF:FF:FF * eth1 10.1.1.171 0x1 0x2 00:A0:C5:E0:C4:EC * eth0 root@Jeff u-boot-0.3.0<1070> You will see Mr. Linux Kernel tries to cheat the host by a wrong MAC address. Below is my environment variable settings special for dear Ms. U-Boot: => printenv baudrate=9600 loads_echo=1 loadaddr=0x01000000 ethaddr=00:04:ac:e3:1d:62 filesize=b6820 netmask=255.255.255.0 ipaddr=7.1.1.6 serverip=7.1.1.4 bootfile=vmlinux.PPCBoot bootargs=console=ttyS0,9600 ip=7.1.1.6:::255.255.255.0:ppclinux:eth0 nfsroot=7.1 .1.4:/exports/eldk/ppc_4xx root=/dev/nfs rw stdin=serial stdout=serial stderr=serial Environment size: 602/4092 bytes => And: => bdi memstart = 0x00000000 memsize = 0x08000000 flashstart = 0xFF800000 flashsize = 0x00480000 flashoffset = 0x00000000 sramstart = 0x00000000 sramsize = 0x00000000 bootflags = 0x00000000 intfreq = 400 MHz busfreq = 133.333 MHz ethaddr = 00:04:AC:E3:1D:62 IP addr = 7.1.1.6 baudrate = 9600 bps => Could anyone give me some hint on these issues? Thanks in advance, -- Jeff H. Zhong ------------- Doremi Labs, Inc. 306 East Alameda Avenue Burbank, CA 91502 Tel : (818) 562 1101 Fax : (818) 562 1109

1 0

[U-Boot-Users] Ebony boot issues -- help wanted
by Jeff H Zhong 16 Apr '03

16 Apr '03

Hi Guys, I am new to both this mailing-list and embedded linuxppc. Currently I am working on IBM ebony evaluation platform, and I got couple of doubts which I can't figure out. I programmed u-boot 3.0.0 into the flash and trying to use NFS to boot the kernel. Here are my questions, 1. At U-Boot phase I got output on console: U-Boot 0.3.0 (Apr 15 2003 - 14:12:33) IBM PowerPC 440 Rev. C Board: IBM 440GP Evaluation Board (Ebony) VCO: 800 MHz CPU: 400 MHz PLB: 133 MHz OPB: 66 MHz EPB: 66 MHz I2C: ready DRAM: I2c read: failed 4 I2c read: failed 4 128 MB FLASH: 4.5 MB PCI: Bus Dev VenId DevId Class Int 00 04 1095 0680 0104 00 In: serial Out: serial Err: serial KGDB: kgdb ready ready BEDBUG:ready => Why u-boot failed on my DRAM I2C read although it still can find out the correctly amount ? At this point of time, I am not able to ping the target from my host(RH 7.3). From the host: root@Jeff u-boot-0.3.0<1063>ping 7.1.1.6 PING 7.1.1.6 (7.1.1.6) from 7.1.1.4 : 56(84) bytes of data. >From 7.1.1.4 icmp_seq=1 Destination Host Unreachable >From 7.1.1.4 icmp_seq=2 Destination Host Unreachable .... root@Jeff u-boot-0.3.0<1064>cat /proc/net/arp IP address HW type Flags HW address Mask Device 7.1.1.6 0x1 0x0 00:00:00:00:00:00 * eth1 10.1.1.171 0x1 0x2 00:A0:C5:E0:C4:EC * eth0 I guess that dear Ms. U-Boot does not bring up arp, is that right? 2. Now, I am trying to tftp kernel image, and on target console: => tftp ENET Speed is 100 Mbps - FULL duplex connection ARP broadcast 1 TFTP from server 7.1.1.4; our IP address is 7.1.1.6 Filename 'vmlinux.PPCBoot'. Load address: 0x1000000 Loading: ################################################################# ################################################################# ########### done Bytes transferred = 718502 (af6a6 hex) => Ok, it got the image. On host side, I have: root@Jeff u-boot-0.3.0<1065>cat /proc/net/arp IP address HW type Flags HW address Mask Device 7.1.1.6 0x1 0x0 00:04:AC:E3:1D:62 * eth1 10.1.1.171 0x1 0x2 00:A0:C5:E0:C4:EC * eth0 Ms. U-Boot looks more pretty and coorprative now, right? But I still couldn't ping her, root@Jeff u-boot-0.3.0<1066>ping 7.1.1.6 PING 7.1.1.6 (7.1.1.6) from 7.1.1.4 : 56(84) bytes of data. >From 7.1.1.4 icmp_seq=1 Destination Host Unreachable >From 7.1.1.4 icmp_seq=2 Destination Host Unreachable ...... 3. Now I am trying to boot up kernel, she says: => bootm ## Booting image at 01000000 ... Image Name: Linux-2.4.21-pre7-big Created: 2003-04-15 18:05:48 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 718438 Bytes = 701.6 kB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Uncompressing Kernel Image ... OK Linux version 2.4.21-pre7-big (root@Jeff) (gcc version 2.95.2 19991024 (release) ) #60 Tue Apr 15 18:04:53 UTC 2003 IBM Ebony port (C) 2002 MontaVista Software, Inc. (source(a)mvista.com) On node 0 totalpages: 32768 zone(0): 4096 pages. zone(1): 28672 pages. zone(2): 0 pages. Kernel command line: console=ttyS0,9600 ip=7.1.1.6:::255.255.255.0:ppclinux:eth0 nfsroot=7.1.1.4:/exports/eldk/ppc_4xx Calibrating delay loop... 599.65 BogoMIPS Memory: 127436k available (1176k kernel code, 420k data, 224k init, 0k highmem) Dentry cache hash table entries: 16384 (order: 5, 131072 bytes) Inode cache hash table entries: 8192 (order: 4, 65536 bytes) Mount cache hash table entries: 512 (order: 0, 4096 bytes) Buffer-cache hash table entries: 8192 (order: 3, 32768 bytes) Page-cache hash table entries: 32768 (order: 5, 131072 bytes) POSIX conformance testing by UNIFIX PCI: Probing PCI hardware Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket Starting kswapd devfs: v1.12c (20020818) Richard Gooch (rgooch(a)atnf.csiro.au) devfs: boot_options: 0x1 Installing knfsd (copyright (C) 1996 okir(a)monad.swb.de). i2c-core.o: i2c core module i2c-dev.o: i2c /dev entries driver module i2c-core.o: driver i2c-dev dummy driver registered. i2c-proc.o version 2.6.1 (20010825) pty: 256 Unix98 ptys configured Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI en abled ttyS00 at 0xfdfe9200 (irq = 0) is a 16550A ttyS01 at 0xfdfe8300 (irq = 1) is a 16550A RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize Zmii bridge in RMII mode eth0: Phy @ 0x8, type Am79c875A (0x00225541) Reset ethernet interfaces Zmii bridge in RMII mode eth1: Phy @ 0x9, type Am79c875A (0x00225541) Reset ethernet interfaces Uniform Multi-Platform E-IDE driver Revision: 7.00beta-2.4 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx SiI680: IDE controller at PCI slot 00:04.0 SiI680: chipset revision 1 SiI680: not 100% native mode: will probe irqs later SiI680: BASE CLOCK == 133 ide0: MMIO-DMA at 0xc900ef00-0xc900ef07, BIOS settings: hda:pio, hdb:pio ide1: MMIO-DMA at 0xc900ef08-0xc900ef0f, BIOS settings: hdc:pio, hdd:pio Probing IDE interface ide0... hda: IBM-DTLA-307015, ATA DISK drive blk: queue c01c10d0, I/O limit 4095Mb (mask 0xffffffff) Probing IDE interface ide1... ide0 at 0xc900ef80-0xc900ef87,0xc900ef8a on irq 26 hda: attached ide-disk driver. hda: host protected area => 1 hda: 30003120 sectors (15362 MB) w/1916KiB Cache, CHS=29765/16/63, UDMA(100) Partition check: /dev/ide/host0/bus0/target0/lun0: [PTBL] [1867/255/63] p1 IBM IIC driver i2c-dev.o: Registered 'IBM IIC adapter' as minor 0 i2c-core.o: adapter IBM IIC adapter registered as adapter 0. i2c-dev.o: Registered 'IBM IIC adapter' as minor 1 i2c-core.o: adapter IBM IIC adapter registered as adapter 1. NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP IP: routing cache hash table of 1024 buckets, 8Kbytes TCP: Hash tables configured (established 8192 bind 8192) eth0: IBM EMAC: link up, 100 Mbps Full Duplex, auto-negotiation complete. eth0: IBM EMAC: MAC ff:ff:ff:ff:ff:ff. eth0: IBM EMAC: open completed IP-Config: Complete: device=eth0, addr=7.1.1.6, mask=255.255.255.0, gw=255.255.255.255, host=ppclinux, domain=, nis-domain=(none), bootserver=255.255.255.255, rootserver=7.1.1.4, rootpath= NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. Looking up port of RPC 100003/2 on 7.1.1.4 Look, Mrs. U-Boot bring up the kernel and Mr. Kernel talks lot but he stucks here refusing to move ahead. Seems like kernel didn't get his MAC address properly, so he couldn't connect to host bootp server. My question is that how does Ms. U-Boot pass the environment variable to Mr. Kernel, as something I got from this archive? On host: root@Jeff u-boot-0.3.0<1067>cat /proc/net/arp IP address HW type Flags HW address Mask Device 7.1.1.6 0x1 0x0 00:04:AC:E3:1D:62 * eth1 10.1.1.171 0x1 0x2 00:A0:C5:E0:C4:EC * eth0 4. Then I issued a ping from host, root@Jeff u-boot-0.3.0<1068>ping 7.1.1.6 PING 7.1.1.6 (7.1.1.6) from 7.1.1.4 : 56(84) bytes of data. 64 bytes from 7.1.1.6: icmp_seq=1 ttl=64 time=0.506 ms 64 bytes from 7.1.1.6: icmp_seq=2 ttl=64 time=0.166 ms 64 bytes from 7.1.1.6: icmp_seq=3 ttl=64 time=0.146 ms 64 bytes from 7.1.1.6: icmp_seq=4 ttl=64 time=0.137 ms 64 bytes from 7.1.1.6: icmp_seq=5 ttl=64 time=0.138 ms 64 bytes from 7.1.1.6: icmp_seq=6 ttl=64 time=0.137 ms ..... This makes Mr. Kernel keep going: Looking up port of RPC 100005/1 on 7.1.1.4 VFS: Mounted root (nfs filesystem). Mounted devfs on /dev Freeing unused kernel memory: 224k init INIT: version 2.78 booting Remounting the root filesystem read-write. Cleaning: /tmp /var/lock /var/run. Mounting local file systems... none on /dev/pts type devpts (rw,gid=5,mode=620) Setting up IP spoofing protection: rp_filter. Configuring network interfaces: done. Starting portmap daemon: portmap. Initializing random number generator... done. INIT: Entering runlevel: 2 Starting system logger: Done Starting kernel logger: Done Starting xinetd: Done Welcome to DoReMi Labs. Inc. ppclinux login: Looks like the kernel got himself's MAC through the icmp message. It is fairly wired to me. At this moment, on host: root@Jeff u-boot-0.3.0<1069>cat /proc/net/arp IP address HW type Flags HW address Mask Device 7.1.1.6 0x1 0x2 FF:FF:FF:FF:FF:FF * eth1 10.1.1.171 0x1 0x2 00:A0:C5:E0:C4:EC * eth0 root@Jeff u-boot-0.3.0<1070> You will see Mr. Linux Kernel tries to cheat the host by a wrong MAC address. Below is my environment variable settings special for dear Ms. U-Boot: => printenv baudrate=9600 loads_echo=1 loadaddr=0x01000000 ethaddr=00:04:ac:e3:1d:62 filesize=b6820 netmask=255.255.255.0 ipaddr=7.1.1.6 serverip=7.1.1.4 bootfile=vmlinux.PPCBoot bootargs=console=ttyS0,9600 ip=7.1.1.6:::255.255.255.0:ppclinux:eth0 nfsroot=7.1 .1.4:/exports/eldk/ppc_4xx root=/dev/nfs rw stdin=serial stdout=serial stderr=serial Environment size: 602/4092 bytes => And: => bdi memstart = 0x00000000 memsize = 0x08000000 flashstart = 0xFF800000 flashsize = 0x00480000 flashoffset = 0x00000000 sramstart = 0x00000000 sramsize = 0x00000000 bootflags = 0x00000000 intfreq = 400 MHz busfreq = 133.333 MHz ethaddr = 00:04:AC:E3:1D:62 IP addr = 7.1.1.6 baudrate = 9600 bps => Could anyone give me some hint on these issues? Thanks in advance, -- Jeff H. Zhong ------------- Doremi Labs, Inc. 306 East Alameda Avenue Burbank, CA 91502 Tel : (818) 562 1101 Fax : (818) 562 1109

1 0

RE: [U-Boot-Users] mpc8245 timer
by DeLaGarza, Robert 16 Apr '03

16 Apr '03

On Tuesday, April 15, 2003 2:00 AM, Wolfgang Denk [SMTP:wd@denx.de] wrote: > In message <01C302F0.40E40DC0.robdlg(a)att.net> you wrote: > > > > ...in Table 11-11 of the _MPC8245 Integrated Processor User's Manual_, > > there is the statement "The timers operate at 1/8 the speed of the SDRAM_CLK signal." > > > > Should the divisor in get_tbclk( ) be 8L for the MPC8245? > > You can easily try it out: how long does "sleep 10" sleep on your system? Yes--thanks. I tested "sleep 10" on both our '8245 reference board (an Artis Microsystems SBC-A3000) and our own custom '8241 board. In both cases, the sleep interval was correct. Thus, the divisor in get_tbclk( ) appears to be fine. I will disregard Table 11-11, as it does not seem to apply here.

1 0

[U-Boot-Users] mpc8245 timer
by DeLaGarza, Robert 15 Apr '03

15 Apr '03

The following code appears in u-boot-0.3.0/cpu/mpc824x/cpu.c /* * Get timebase clock frequency (like cpu_clk in Hz) * This is the sys_logic_clk (memory bus) divided by 4 */ unsigned long get_tbclk (void) { return ((get_bus_freq (0) + 2L) / 4L); } However, in Table 11-11 of the _MPC8245 Integrated Processor User's Manual_, there is the statement "The timers operate at 1/8 the speed of the SDRAM_CLK signal." Should the divisor in get_tbclk( ) be 8L for the MPC8245? (I know there are several '8245 and '8241 boards using PPCBoot and/or U-Boot, so my guess is that the manual is wrong, but I didn't see anything in the errata about this.)

2 1

RE: [U-Boot-Users] DYNAMIC_CRC_TABLE ????
by DeLaGarza, Robert 15 Apr '03

15 Apr '03

On Tuesday, April 15, 2003 1:21 AM, Steven Scholz [SMTP:steven.scholz@imc-berlin.de] wrote: > The file crc32.c contains some #ifdef DYNAMIC_CRC_TABLE . > > What's the purpose of that? > Are there any advantages of defining that? > That directive enables one to create the crc_table[256] array at run time, rather than compiling it into the code. One advantage of doing this is that it reduces the size of the code; only the function used to generate the table needs to be stored in non-volatile memory, rather than the entire table (for a 32-bit long, the table will occupy 1 kilobyte of memory).

1 0

[U-Boot-Users] DYNAMIC_CRC_TABLE ????
by Steven Scholz 15 Apr '03

15 Apr '03

Hi there, The file crc32.c contains some #ifdef DYNAMIC_CRC_TABLE . What's the purpose of that? Are there any advantages of defining that? Thanks, Steven

1 0

[U-Boot-Users] how to build and work with FADS862T?
by Masayuki Takagiwa 15 Apr '03

15 Apr '03

Hi, It doesn't start though it is trying to use U-boat on the FADS862T at present. Will there be a wrong point about the way of building it? Or, is it wrong from building of the environment? My environment is as the following. PC : VMware 3.2.0 OS : RedHat Linux 8.0 (with Japanese support) gcc etc. : ELDK 2.0.2 U-Boot 0.2.0 released (CVS isn't being used.) Debug interface : BDI2000 It does as the following on this, and it is being built. # export CROSS_COMPILE=ppc_8xx- # make clean # make FADS860T_config # make all The S-file which it could get in this more is being written via the BDI2000. A .cfg file uses the attached one for ADS860 for the adapter. Warning and an error were only warning by the start.S here. It is written in the IMMR register, and it is a place to jump to init_board_f, and an exception seems to occur. Only, action seems to vary according to the setup of the break point, and a cause can't be grasped. Incidentally, it seemed that the binary of the source written in the FlashROM was correct. To the point which it jumped, though it isn't being followed, Won't I be able to accept anyone advice? # This mail changes with a translation machine from Japanese. There may be a sentence which is hard to read. Thanks. --------------------------------------- Masayuki Takagiwa @ ETNA corp. takagiwa(a)tokyo.etna.co.jp ---------------------------------------

2 3

Re: [U-Boot-Users] Re: Interrupt management under PPC4xx platform
by llandre 15 Apr '03

15 Apr '03

> >You could ask the linuxppc-embedded mailing-list. I think that MontaVista >has linux running on the PPC405EP eval board (bubinga == evb405ep). They >could have a hint about differences in the 405 EMAC implementations... Hi Stefan. Yes, you're right. The kernel has been ported to this platform and I have already run it through the OpenBIOS monitor. I'll follow your suggestion and I'll post a message to linuxppc-embedded ml. Thanx for your help. llandre

1 0