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