* RedBoot built with gcc 3.4.4 @ 2007-02-07 11:52 Guennadi Liakhovetski 2007-02-07 12:11 ` Andrew Lunn 0 siblings, 1 reply; 16+ messages in thread From: Guennadi Liakhovetski @ 2007-02-07 11:52 UTC (permalink / raw) To: ecos-devel Hi all I've built redboot for an XSCALE PXA270 based board from eCos CVS snapshot around December 2006. What built with gcc 3.3.2 binutils 2.14.90 redboot works fine. When built with gcc 3.4.4 binutils 2.15.96 it comes to Reset caused by: hardware reset pin Core voltage will be set to 1.150 Volts. Clock speed will be changed to 208 MHz clock speed set to 208 MHz ... + and then comes a string $T0a0f:58ab00a0;0d:34d500a0;#0b and it keeps repeating on every ENTER. I was told that this string comes from some debugging mode, which is invoked due to some unrecognised exception. Here are the used flags -O2 -ffunction-sections -fdata-sections -fno-rtti -fno-builtin \ -fno-exceptions -fvtable-gc -finit-priority -mapcs-frame Originally there was also a "-g" there, which I now removed, and haven't yet checked if the problem is still there, but I think it is not the reason. Is the problem known to anybody / how do we solve it? Thanks Guennadi --------------------------------- Guennadi Liakhovetski, Ph.D. DSA Daten- und Systemtechnik GmbH Pascalstr. 28 D-52076 Aachen Germany ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: RedBoot built with gcc 3.4.4 2007-02-07 11:52 RedBoot built with gcc 3.4.4 Guennadi Liakhovetski @ 2007-02-07 12:11 ` Andrew Lunn 2007-02-07 12:43 ` Guennadi Liakhovetski 0 siblings, 1 reply; 16+ messages in thread From: Andrew Lunn @ 2007-02-07 12:11 UTC (permalink / raw) To: Guennadi Liakhovetski; +Cc: ecos-devel On Wed, Feb 07, 2007 at 12:52:43PM +0100, Guennadi Liakhovetski wrote: > Hi all > > I've built redboot for an XSCALE PXA270 based board from eCos CVS snapshot > around December 2006. What built with gcc 3.3.2 binutils 2.14.90 redboot > works fine. When built with gcc 3.4.4 binutils 2.15.96 it comes to > > Reset caused by: hardware reset pin > Core voltage will be set to 1.150 Volts. > Clock speed will be changed to 208 MHz > clock speed set to 208 MHz ... > + > > and then comes a string > > $T0a0f:58ab00a0;0d:34d500a0;#0b > > and it keeps repeating on every ENTER. I was told that this string comes > from some debugging mode, which is invoked due to some unrecognised > exception. Correct. Use gdb and find out where it crashed. It can decode the string to give you an address. You might also want to try the old gcc with the new binutils, and the new gcc with the old binutils etc to find out which is the problem. Andrew ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: RedBoot built with gcc 3.4.4 2007-02-07 12:11 ` Andrew Lunn @ 2007-02-07 12:43 ` Guennadi Liakhovetski 2007-02-07 12:52 ` Andrew Lunn 2007-02-07 12:56 ` Edgar Grimberg 0 siblings, 2 replies; 16+ messages in thread From: Guennadi Liakhovetski @ 2007-02-07 12:43 UTC (permalink / raw) To: Andrew Lunn; +Cc: ecos-devel On Wed, 7 Feb 2007, Andrew Lunn wrote: >> $T0a0f:58ab00a0;0d:34d500a0;#0b >> >> and it keeps repeating on every ENTER. I was told that this string comes >> from some debugging mode, which is invoked due to some unrecognised >> exception. > > Correct. Use gdb and find out where it crashed. It can decode the > string to give you an address. Ok, a short look through eCos / RedBoot docs didn't reveal anything. Could you, please, give some short instructions? I used gdb also remotely, but with the bdi2000 stub... And never heard of such cryptic lines. How do I debug it? I'll try to look further. Thanks Guennadi --------------------------------- Guennadi Liakhovetski, Ph.D. DSA Daten- und Systemtechnik GmbH Pascalstr. 28 D-52076 Aachen Germany ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: RedBoot built with gcc 3.4.4 2007-02-07 12:43 ` Guennadi Liakhovetski @ 2007-02-07 12:52 ` Andrew Lunn 2007-02-07 13:00 ` Guennadi Liakhovetski 2007-02-07 12:56 ` Edgar Grimberg 1 sibling, 1 reply; 16+ messages in thread From: Andrew Lunn @ 2007-02-07 12:52 UTC (permalink / raw) To: Guennadi Liakhovetski; +Cc: Andrew Lunn, ecos-devel On Wed, Feb 07, 2007 at 01:43:35PM +0100, Guennadi Liakhovetski wrote: > On Wed, 7 Feb 2007, Andrew Lunn wrote: > > >>$T0a0f:58ab00a0;0d:34d500a0;#0b > >> > >>and it keeps repeating on every ENTER. I was told that this string comes > >>from some debugging mode, which is invoked due to some unrecognised > >>exception. > > > >Correct. Use gdb and find out where it crashed. It can decode the > >string to give you an address. > > Ok, a short look through eCos / RedBoot docs didn't reveal anything. Could > you, please, give some short instructions? I used gdb also remotely, but > with the bdi2000 stub... And never heard of such cryptic lines. How do I > debug it? I'll try to look further. http://ecos.sourceware.org/docs-latest/user-guide/user-guide-installation-target.html Connect the serial port of your PC to the serial port of your device. start gdb with the elf or redboot. gdb redboot.elf target remote /dev/ttyS0 bt Andrew ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: RedBoot built with gcc 3.4.4 2007-02-07 12:52 ` Andrew Lunn @ 2007-02-07 13:00 ` Guennadi Liakhovetski 2007-02-07 13:03 ` Gary Thomas 0 siblings, 1 reply; 16+ messages in thread From: Guennadi Liakhovetski @ 2007-02-07 13:00 UTC (permalink / raw) To: Andrew Lunn; +Cc: ecos-devel On Wed, 7 Feb 2007, Andrew Lunn wrote: > gdb redboot.elf > target remote /dev/ttyS0 > bt Ok, thanks. Here: (gdb) bt #0 0xa0011bb4 in workspace_start () #1 0x18e59ff0 in ?? () #2 0xa000d79c in __startup_stack_base () Cannot access memory at address 0xe3e85dd9 Will look at that workspace_start, if I can identify anything... Thanks Guennadi --------------------------------- Guennadi Liakhovetski, Ph.D. DSA Daten- und Systemtechnik GmbH Pascalstr. 28 D-52076 Aachen Germany ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: RedBoot built with gcc 3.4.4 2007-02-07 13:00 ` Guennadi Liakhovetski @ 2007-02-07 13:03 ` Gary Thomas 2007-02-07 13:24 ` Guennadi Liakhovetski 0 siblings, 1 reply; 16+ messages in thread From: Gary Thomas @ 2007-02-07 13:03 UTC (permalink / raw) To: Guennadi Liakhovetski; +Cc: Andrew Lunn, ecos-devel Guennadi Liakhovetski wrote: > On Wed, 7 Feb 2007, Andrew Lunn wrote: > >> gdb redboot.elf >> target remote /dev/ttyS0 >> bt > > Ok, thanks. Here: > > (gdb) bt > #0 0xa0011bb4 in workspace_start () > #1 0x18e59ff0 in ?? () > #2 0xa000d79c in __startup_stack_base () > Cannot access memory at address 0xe3e85dd9 > > Will look at that workspace_start, if I can identify anything... Those are all data addresses (that RedBoot uses), so it looks like it has jumped into space... You'll be better off restarting it using GDB and step through to find out where it goes wrong. -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: RedBoot built with gcc 3.4.4 2007-02-07 13:03 ` Gary Thomas @ 2007-02-07 13:24 ` Guennadi Liakhovetski 2007-02-07 13:42 ` Gary Thomas 0 siblings, 1 reply; 16+ messages in thread From: Guennadi Liakhovetski @ 2007-02-07 13:24 UTC (permalink / raw) To: Gary Thomas; +Cc: Andrew Lunn, ecos-devel On Wed, 7 Feb 2007, Gary Thomas wrote: > You'll be better off restarting it using GDB and step > through to find out where it goes wrong. hm, that requires gdb support from the redboot, which I am not sure if I have. It crashes somewhere inside bootp. "+" is where it starts sending bootp requests. So, I could set a breakpoint on __bootp_find_local_ip (is this the right function for it?), but how do I reset the board from under gdb? and will it directly contact the gdb stub on the board and set the breakpoint? Thanks Guennadi --------------------------------- Guennadi Liakhovetski, Ph.D. DSA Daten- und Systemtechnik GmbH Pascalstr. 28 D-52076 Aachen Germany ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: RedBoot built with gcc 3.4.4 2007-02-07 13:24 ` Guennadi Liakhovetski @ 2007-02-07 13:42 ` Gary Thomas 2007-02-07 13:59 ` Guennadi Liakhovetski 0 siblings, 1 reply; 16+ messages in thread From: Gary Thomas @ 2007-02-07 13:42 UTC (permalink / raw) To: Guennadi Liakhovetski; +Cc: ecos-devel Guennadi Liakhovetski wrote: > On Wed, 7 Feb 2007, Gary Thomas wrote: > >> You'll be better off restarting it using GDB and step >> through to find out where it goes wrong. > > hm, that requires gdb support from the redboot, which I am not sure if I > have. It crashes somewhere inside bootp. "+" is where it starts sending > bootp requests. So, I could set a breakpoint on __bootp_find_local_ip > (is this the right function for it?), but how do I reset the board from > under gdb? and will it directly contact the gdb stub on the board and > set the breakpoint? To debug RedBoot, you'll need to use your BDI. Simply connect GDB to the BDI instead of the serial port. Something like this: (gdb) tar rem bdi:2001 where 'bdi' is the DNS name or IP of your unit. It has commands for resetting the device, setting hardware breakpoints, etc. Read the BDI manual for the details. Then you can step through the RedBoot code to find out where it's going bad. -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: RedBoot built with gcc 3.4.4 2007-02-07 13:42 ` Gary Thomas @ 2007-02-07 13:59 ` Guennadi Liakhovetski 2007-02-07 14:32 ` Gary Thomas 0 siblings, 1 reply; 16+ messages in thread From: Guennadi Liakhovetski @ 2007-02-07 13:59 UTC (permalink / raw) To: Gary Thomas; +Cc: ecos-devel On Wed, 7 Feb 2007, Gary Thomas wrote: > To debug RedBoot, you'll need to use your BDI. > > Simply connect GDB to the BDI instead of the serial port. > Something like this: > (gdb) tar rem bdi:2001 Aha, ok, this makes sense, but, unfortunately, bdi doesn't work with this board. It worked somehow with pxa255 (not very reliably) and I haven't been able to use it with pxa270. Yes, I do have the necessary register description etc. files, just it wouldn't work. So, I guess, it's not an option for me. I could disable bootp, but the point was not to somehow get it to build and run, but to find the reason of the mis-compilation and (preferrably) fix redboot. Besides, every non-booting redboot means about 20 minutes jtag flashing... Thanks Guennadi --------------------------------- Guennadi Liakhovetski, Ph.D. DSA Daten- und Systemtechnik GmbH Pascalstr. 28 D-52076 Aachen Germany ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: RedBoot built with gcc 3.4.4 2007-02-07 13:59 ` Guennadi Liakhovetski @ 2007-02-07 14:32 ` Gary Thomas 2007-02-09 7:55 ` Guennadi Liakhovetski 0 siblings, 1 reply; 16+ messages in thread From: Gary Thomas @ 2007-02-07 14:32 UTC (permalink / raw) To: Guennadi Liakhovetski; +Cc: ecos-devel Guennadi Liakhovetski wrote: > On Wed, 7 Feb 2007, Gary Thomas wrote: > >> To debug RedBoot, you'll need to use your BDI. >> >> Simply connect GDB to the BDI instead of the serial port. >> Something like this: >> (gdb) tar rem bdi:2001 > > Aha, ok, this makes sense, but, unfortunately, bdi doesn't work with > this board. It worked somehow with pxa255 (not very reliably) and I > haven't been able to use it with pxa270. Yes, I do have the necessary > register description etc. files, just it wouldn't work. So, I guess, > it's not an option for me. I could disable bootp, but the point was not > to somehow get it to build and run, but to find the reason of the > mis-compilation and (preferrably) fix redboot. Besides, every > non-booting redboot means about 20 minutes jtag flashing... In that case, what I would do is install a working RedBoot (built with 3.3.2) and then experiment with a RAM version built with the new tools. Put in some diag_printf() to trace the code. You might even be able to debug this using the serial connection and GDB (since that does seem to be alive in your ROM/ROMRAM version) -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: RedBoot built with gcc 3.4.4 2007-02-07 14:32 ` Gary Thomas @ 2007-02-09 7:55 ` Guennadi Liakhovetski 2007-02-09 9:53 ` Guennadi Liakhovetski 0 siblings, 1 reply; 16+ messages in thread From: Guennadi Liakhovetski @ 2007-02-09 7:55 UTC (permalink / raw) To: Gary Thomas; +Cc: ecos-devel On Wed, 7 Feb 2007, Gary Thomas wrote: > In that case, what I would do is install a working RedBoot > (built with 3.3.2) and then experiment with a RAM version > built with the new tools. Put in some diag_printf() to > trace the code. You might even be able to debug this > using the serial connection and GDB (since that does > seem to be alive in your ROM/ROMRAM version) Well, yeah, looked shortly at this, but RAM build is not supported on this plaform and a quick try wasn't successful. OTOH, I realised, that I, probably, was wrong about where it crashes. The last messages that I see are from CPU clock switching code. I looked in those disassembled functions - they are VERY different. And I noticed that RedBoot / eCos doesn't specify any ARM version specific options. This toolchain builds kernels just fine, but the kernel does provide a few CPU-specific options. It also compiles user-space applications fine without any options - but that is user-space. So, there might be a problem with some supervisor mode insn. I tried adding "-mapcs-frame -march=armv5te -mtune=xscale -Wa,-mcpu=xscale" to c-flags, it didn't help. Looking further Thanks Guennadi --------------------------------- Guennadi Liakhovetski, Ph.D. DSA Daten- und Systemtechnik GmbH Pascalstr. 28 D-52076 Aachen Germany ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: RedBoot built with gcc 3.4.4 2007-02-09 7:55 ` Guennadi Liakhovetski @ 2007-02-09 9:53 ` Guennadi Liakhovetski 2007-02-09 10:18 ` Guennadi Liakhovetski 2007-02-12 18:36 ` Kurt Siedenburg 0 siblings, 2 replies; 16+ messages in thread From: Guennadi Liakhovetski @ 2007-02-09 9:53 UTC (permalink / raw) To: Gary Thomas; +Cc: ecos-devel On Fri, 9 Feb 2007, Guennadi Liakhovetski wrote: > Looking further Auch... I came as far as to the loop /*------------------------------------------------------------------------*/ /* C++ support - run initial constructors */ #ifdef CYGSEM_HAL_STOP_CONSTRUCTORS_ON_FLAG cyg_bool cyg_hal_stop_constructors; #endif typedef void (*pfunc) (void); extern pfunc __CTOR_LIST__[]; extern pfunc __CTOR_END__[]; void cyg_hal_invoke_constructors (void) { #ifdef CYGSEM_HAL_STOP_CONSTRUCTORS_ON_FLAG static pfunc *p = &__CTOR_END__[-1]; cyg_hal_stop_constructors = 0; for (; p >= __CTOR_LIST__; p--) { diag_printf("Invoking constructor @ 0x%08x\n", *p); (*p) (); if (cyg_hal_stop_constructors) { p--; break; } } #else pfunc *p; for (p = &__CTOR_END__[-1]; p >= __CTOR_LIST__; p--) { diag_printf("Invoking constructor @ 0x%08x\n", *p); (*p) (); } #endif And put the diag_printf() there... And it prints 1 address and that's it... So, do I understand it right that here it is supposed to call C++ constructors?... Oh, no... and already in the first one it crashes... So, some C++ internal calling conventions have changed. I am pretty helpless in what concerns C++ ABI... Anyone? Thanks Guennadi --------------------------------- Guennadi Liakhovetski, Ph.D. DSA Daten- und Systemtechnik GmbH Pascalstr. 28 D-52076 Aachen Germany ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: RedBoot built with gcc 3.4.4 2007-02-09 9:53 ` Guennadi Liakhovetski @ 2007-02-09 10:18 ` Guennadi Liakhovetski 2007-02-12 18:36 ` Kurt Siedenburg 1 sibling, 0 replies; 16+ messages in thread From: Guennadi Liakhovetski @ 2007-02-09 10:18 UTC (permalink / raw) To: Gary Thomas; +Cc: ecos-devel Hm, can it be "-finit-priority". It errors in 3.4.4, so, I took it out, which works fine with other "recent" compilers. And here: http://sources.redhat.com/ml/ecos-devel/2003-10/msg00061.html <quote> Gary> That's really too bad - we can't take it out globally Gary> because that could possibly break things for folks using Gary> older compilers and we may have troubles using newer ones.. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ </quote> It has been verified that it is not needed on even 2.95.x and taken away from in-tree platforms. Can it be that we DO have a problem now? Guennadi --------------------------------- Guennadi Liakhovetski, Ph.D. DSA Daten- und Systemtechnik GmbH Pascalstr. 28 D-52076 Aachen Germany ^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: RedBoot built with gcc 3.4.4 2007-02-09 9:53 ` Guennadi Liakhovetski 2007-02-09 10:18 ` Guennadi Liakhovetski @ 2007-02-12 18:36 ` Kurt Siedenburg 2007-02-13 17:12 ` Guennadi Liakhovetski 1 sibling, 1 reply; 16+ messages in thread From: Kurt Siedenburg @ 2007-02-12 18:36 UTC (permalink / raw) To: Guennadi Liakhovetski, Gary Thomas; +Cc: ecos-devel I'd be interested in the answer to this question also - although our situation is different: - We have seen the same crash you observed. However - It happens *very* rarely. Over a period of 12 months I've seen it 3 times. Thus in >99.9(9)% of bootups it works fine. However - once it gets into this state - chances are it can be repro'd. - We have no idea how to reproduce the problem. - We use a pretty old version of ecos (1.3 based). - We use gcc 2.95.3 - Our CPU is Xscale Looking at the differences (eg. reproducibility) I think that the root cause of our problems is likely to be different. Nevertheless I'd be interested in the solution to your problem. Maybe it applies to us also. Just looking at our symptoms I'd think there's some uninitialized variable somewhere in early ecos startup. And most of the times it contains a value not causing trouble. Only occasionally ... . Regards, Kurt Siedenburg -----Original Message----- From: ecos-devel-owner@ecos.sourceware.org [mailto:ecos-devel-owner@ecos.sourceware.org] On Behalf Of Guennadi Liakhovetski Sent: Friday, February 09, 2007 1:53 AM To: Gary Thomas Cc: ecos-devel@ecos.sourceware.org Subject: Re: RedBoot built with gcc 3.4.4 On Fri, 9 Feb 2007, Guennadi Liakhovetski wrote: > Looking further Auch... I came as far as to the loop /*---------------------------------------------------------------------- --*/ /* C++ support - run initial constructors */ #ifdef CYGSEM_HAL_STOP_CONSTRUCTORS_ON_FLAG cyg_bool cyg_hal_stop_constructors; #endif typedef void (*pfunc) (void); extern pfunc __CTOR_LIST__[]; extern pfunc __CTOR_END__[]; void cyg_hal_invoke_constructors (void) { #ifdef CYGSEM_HAL_STOP_CONSTRUCTORS_ON_FLAG static pfunc *p = &__CTOR_END__[-1]; cyg_hal_stop_constructors = 0; for (; p >= __CTOR_LIST__; p--) { diag_printf("Invoking constructor @ 0x%08x\n", *p); (*p) (); if (cyg_hal_stop_constructors) { p--; break; } } #else pfunc *p; for (p = &__CTOR_END__[-1]; p >= __CTOR_LIST__; p--) { diag_printf("Invoking constructor @ 0x%08x\n", *p); (*p) (); } #endif And put the diag_printf() there... And it prints 1 address and that's it... So, do I understand it right that here it is supposed to call C++ constructors?... Oh, no... and already in the first one it crashes... So, some C++ internal calling conventions have changed. I am pretty helpless in what concerns C++ ABI... Anyone? Thanks Guennadi --------------------------------- Guennadi Liakhovetski, Ph.D. DSA Daten- und Systemtechnik GmbH Pascalstr. 28 D-52076 Aachen Germany ^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: RedBoot built with gcc 3.4.4 2007-02-12 18:36 ` Kurt Siedenburg @ 2007-02-13 17:12 ` Guennadi Liakhovetski 0 siblings, 0 replies; 16+ messages in thread From: Guennadi Liakhovetski @ 2007-02-13 17:12 UTC (permalink / raw) To: Kurt Siedenburg; +Cc: Gary Thomas, ecos-devel On Mon, 12 Feb 2007, Kurt Siedenburg wrote: > I'd be interested in the answer to this question also - although our > situation is different: Yes, looks like your situation is very different. You have a runtime problem, whereas I have a compile / link-time one. ...and I am afraid I am not much nearer to the solution now than before. I thought I identified the exact crash location with the help of debugging printf's, but it looks like the crash / run behaviour differs also with the amount and kind of debugging. Now what I currently cannot understand is how one is supposed to handle the .fixed_vectors section (ARM). This section contains some objects, which are allocated in packages/hal/arm/arch/current/src/vectors.S (although, I don't see any need for assembly, couldn't one just use an appropriate __attribute__ and define those objects in a C file?) and then should be described in the system linker script using the macro: #define SECTION_fixed_vectors(_region_, _vma_, _lma_) \ .fixed_vectors _vma_ : _lma_ \ { FORCE_OUTPUT; KEEP (*(.fixed_vectors)) } \ > _region_ in packages/hal/arm/arch/current/src/arm.ld. Now, those objects will be written at run time, so, the section has to be in RAM. However, I do not understand how this is achieved? As you dont have any loader, you have to initialise it explicitely like the .bss or the .data, which I can perfectly recognize in the above 2 files - as _start and _end addresses are defined, and then the area between them is either cleared (for .bss) or copied from the original image location (.data). But I don't understand how this is supposed to work with .fixed_vectors. Please, explain. Thanks Guennadi --------------------------------- Guennadi Liakhovetski, Ph.D. DSA Daten- und Systemtechnik GmbH Pascalstr. 28 D-52076 Aachen Germany ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: RedBoot built with gcc 3.4.4 2007-02-07 12:43 ` Guennadi Liakhovetski 2007-02-07 12:52 ` Andrew Lunn @ 2007-02-07 12:56 ` Edgar Grimberg 1 sibling, 0 replies; 16+ messages in thread From: Edgar Grimberg @ 2007-02-07 12:56 UTC (permalink / raw) To: Guennadi Liakhovetski, ecos-devel > > Ok, a short look through eCos / RedBoot docs didn't reveal anything. > Could you, please, give some short instructions? I used gdb also > remotely, but with the bdi2000 stub... And never heard of such cryptic > lines. How do I debug it? I'll try to look further. > Replace the target remote <IP>:2001 with target remote <serial_channel> Using gdb: (gdb) help target remote Use a remote computer via a serial line, using a gdb-specific protocol. Specify the serial device it is connected to (e.g. /dev/ttyS0, /dev/ttya, COM1, etc.). Edgar PS: if you have the BDI2000 connected to the target, you better use that instead of serial debugging. ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2007-02-13 17:12 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2007-02-07 11:52 RedBoot built with gcc 3.4.4 Guennadi Liakhovetski 2007-02-07 12:11 ` Andrew Lunn 2007-02-07 12:43 ` Guennadi Liakhovetski 2007-02-07 12:52 ` Andrew Lunn 2007-02-07 13:00 ` Guennadi Liakhovetski 2007-02-07 13:03 ` Gary Thomas 2007-02-07 13:24 ` Guennadi Liakhovetski 2007-02-07 13:42 ` Gary Thomas 2007-02-07 13:59 ` Guennadi Liakhovetski 2007-02-07 14:32 ` Gary Thomas 2007-02-09 7:55 ` Guennadi Liakhovetski 2007-02-09 9:53 ` Guennadi Liakhovetski 2007-02-09 10:18 ` Guennadi Liakhovetski 2007-02-12 18:36 ` Kurt Siedenburg 2007-02-13 17:12 ` Guennadi Liakhovetski 2007-02-07 12:56 ` Edgar Grimberg
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).