This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: i386 platform !
Nothing confidential. I am currently experimenting with getting the RAM
size from GRUB. (we are currently using two boot loaders because it is
simpler for our development environment. So our Redboot is set-up to
load from GRUB and then our application is set to "Load High" at 2M.) So
you will probably want to remove these lines for grub start-up.
cdl_component CYGPKG_HAL_I386_PCMB_MEMSIZE {
user_value GRUB
};
And if you want to build a FLOPPY image, change
cdl_component CYG_HAL_STARTUP {
user_value GRUB
};
to
cdl_component CYG_HAL_STARTUP {
user_value FLOPPY
};
Jean-François Mullet wrote:
Hi,
On my previous mail I was talking about tftp to demonstrate that I was able to communicate with the target. I do not want to use that feature but gdb transfer instead. The previous log has been recorded without any application already running or transferred and as you can see in the log the problem occurs before the application transfer with gdb. The problem is not a IP conflict.
Concerning the first channel communication that's what I saw on the documentation at multiple places; that should be true...
Are you using a recent eCos source code?
I don't know if you have confidential stuff in your redboot image but in other case would you please send me the ecc file and eventually the image you are using?
As I said in a previous mail, the only image I was able to test successfully is a 2 years old prebuild image. Even a recent prebuild image generates the log below.
JF
-----Message d'origine-----
De : David Brennan [mailto:eCos@brennanhome.com]
Envoyé : Saturday, November 13, 2004 16:30
À : Jean-François Mullet
Cc : Gary Thomas; ecos-discuss@sources.redhat.com
Objet : Re: [ECOS] i386 platform !
Have you tried just connecting to redboot with GDB before uploading the
application? I think (someone can correct me on this) that Redboot will
only "talk" on its first communication channel. So if you load the
application with tftp, it assumes that you will not be using gdb. I use
redboot with a i386 platform, and it was working fine until my
application got really big. I'm still working on solving that, but I can
run all of the ecos tests on it. Also make sure you application has a
different IP address than redboot. (once you get that far.)
David Brennan
Jean-François Mullet wrote:
Hi Gary,
The connection between the host and the target is OK because I can upload the application using tftp and run it without any problem.
Here is a screenshot of host console (I do not have serial port):
(gdb) set debug remote 1
(gdb) target remote 192.168.0.10:9000
Remote debugging using 192.168.0.10:9000
Sending packet: $Hc-1#09...putpkt: Junk: RedBoot>
Ack
Packet received: OK
Sending packet: $qC#b4...Ack
Packet received: E02
Sending packet: $qOffsets#4b...Ack
Packet received:
Sending packet: $?#3f...Ack
Packet received: S05
Sending packet: $Hg0#df...Ack
Packet received: OK
Sending packet: $g#67...Sending packet: $g#67...Sending packet: $g#67...Sending
packet: $g#67...Timed out.
Timed out.
Timed out.
Ignoring packet error, continuing...
Bad register packet; fetching a new packet
Timed out.
Timed out.
Timed out.
Ignoring packet error, continuing...
Bad register packet; fetching a new packet
Timed out.
Timed out.
Timed out.
Ignoring packet error, continuing...
Bad register packet; fetching a new packet
Timed out.
Timed out.
Couldn't establish connection to remote target
Remote communication error: Connection reset by peer.
Concerning the x86 as an embedded CPU I do agree with you in a general case but the board I'm using is a fanless PC-104 powered by a STPC Elite.
PC104 consortium: http://www.pc104.org/.
It's far away from a recent powerpc but I do not plan to implement any "fat" algorithm. I'm using this kind of board to take advantage of extension boards. The extension bus is based on the PC ISA bus which is obsolete in general case; I may change architecture when the concept will be validated. I will then perhaps try a more eCos conventional CPU ;-).
JF
-----Message d'origine-----
De : Gary Thomas [mailto:gary@mlbassoc.com]
Envoyé : Friday, November 12, 2004 23:40
À : Jean-François Mullet
Cc : Andrew Lunn; ecos-discuss@sources.redhat.com
Objet : RE: [ECOS] i386 platform !
On Fri, 2004-11-12 at 15:36, Jean-François Mullet wrote:
Hi Andrew,
I can build an image without any problem; I just cannot connect to it with gdb.
I've tested eCos versions (randomly) from two years ago till the last version
on CVS and I've never been able to connect with gdb.
Sometimes the toolchain is not compatible with the eCos source code (compilation
options...) but the error is obvious and an update is easy and fast.
Are you sure you have communication between your host and the target
board? e.g. you should be able to connect to the target via a serial
connection using something like minicom (Linux) or hyperterm (Windows).
Set the baud rate, etc. You should get the RedBoot prompt. Then to
test the GDB connection, try typing this: $g#67 You won't see anything
get echoed, but you should see some characters come back on the
terminal. If that works, you should be able to get into gdb.
Once you know the basic communication is working, try this:
* run GDB on the host
(gdb) set remotebaud 38400
(gdb) set remotedebug 1
(gdb) tar rem /dev/ttyS0 (on Linux)
(gdb) tar rem com1 (on Windows)
Let us know if this doesn't help.
It would be nice to know on which platform people are using eCos.
It seems that x86 is not the most used according the number of
relative questions on the mailing list.
Indeed - the x86 is not really an embedded platform :-) Most eCos
platforms are based on PowerPC, ARM or MIPS embedded processors.
JF
-----Message d'origine-----
De : Andrew Lunn [mailto:andrew@lunn.ch]
Envoyé : Friday, November 12, 2004 16:01
À : Jean-François Mullet
Cc : ecos-discuss@sources.redhat.com
Objet : Re: [ECOS] i386 platform !
On Fri, Nov 12, 2004 at 02:45:30PM +0100, Jean-Fran?ois Mullet wrote:
Hi,
I'm trying to setup a redboot image to accept remote gdb debug on
i386 target (which is supposed to be really easy !).
The only working configuration have been able to use is the prebuild
version actually in CVS which is more than 2 years old.
Any other prebuild version or any version I can build whatever the
ecos, cygwin and toolchain version I'm using is not accepting gdb
remote connection.
How are you building it. I just built one:
lunn@londo:~/eCos/work2$ ecosconfig new pc redboot
U CYGSEM_HAL_USE_ROM_MONITOR, new inferred value 0
U CYGIMP_HAL_COMMON_INTERRUPTS_USE_INTERRUPT_STACK, new inferred value 0
lunn@londo:~/eCos/work2$ ecosconfig import ../anoncvs-clean/packages/hal/i386/pc/current/misc/redboot_FLOPPY.ecm
U CYGHWR_HAL_I386_FPU_SWITCH_LAZY, new inferred value 0
lunn@londo:~/eCos/work2$ ecosconfig tree
lunn@londo:~/eCos/work2$ make -s
headers finished
/home/lunn/eCos/anoncvs-clean/packages/devs/eth/intel/i82559/current/src/if_i82559.c: In function `i82559_start':
/home/lunn/eCos/anoncvs-clean/packages/devs/eth/intel/i82559/current/src/if_i82559.c:1664: warning: implicit declaration of function `memset'
/home/lunn/eCos/anoncvs-clean/packages/devs/eth/intel/i82559/current/src/if_i82559.c: In function `i82559_recv':
/home/lunn/eCos/anoncvs-clean/packages/devs/eth/intel/i82559/current/src/if_i82559.c:2135: warning: implicit declaration of function `memcpy'
/home/lunn/eCos/anoncvs-clean/packages/devs/eth/intel/i82559/current/src/if_i82559.c: At top level:
/home/lunn/eCos/anoncvs-clean/packages/devs/eth/intel/i82559/current/src/if_i82559.c:2712: warning: `eth_dsr' defined but not used
/home/lunn/eCos/anoncvs-clean/packages/hal/common/current/src/hal_stub.c: In function `handle_exception_cleanup':
/home/lunn/eCos/anoncvs-clean/packages/hal/common/current/src/hal_stub.c:457: warning: comparison between pointer and integer
/home/lunn/eCos/anoncvs-clean/packages/redboot/current/src/fs/disk.c: In function `find_dos_partitions':
/home/lunn/eCos/anoncvs-clean/packages/redboot/current/src/fs/disk.c:94: warning: unused variable `tmp'
build finished
I don't have an i386 board to test it with, but it seems to compile OK
except for some warnings.
Andrew
cdl_savefile_version 1;
cdl_savefile_command cdl_savefile_version {};
cdl_savefile_command cdl_savefile_command {};
cdl_savefile_command cdl_configuration { description hardware template package };
cdl_savefile_command cdl_package { value_source user_value wizard_value inferred_value };
cdl_savefile_command cdl_component { value_source user_value wizard_value inferred_value };
cdl_savefile_command cdl_option { value_source user_value wizard_value inferred_value };
cdl_savefile_command cdl_interface { value_source user_value wizard_value inferred_value };
cdl_configuration eCos {
description "" ;
hardware pc ;
template redboot ;
package -hardware CYGPKG_HAL_I386 current ;
package -hardware CYGPKG_HAL_I386_GENERIC current ;
package -hardware CYGPKG_HAL_I386_PC current ;
package -hardware CYGPKG_HAL_I386_PCMB current ;
package -hardware CYGPKG_IO_PCI current ;
package -hardware CYGPKG_IO_SERIAL_GENERIC_16X5X current ;
package -hardware CYGPKG_IO_SERIAL_I386_PC current ;
package -hardware CYGPKG_DEVS_ETH_INTEL_I82559 current ;
package -hardware CYGPKG_DEVS_ETH_I386_PC_I82559 current ;
package -hardware CYGPKG_DEVICES_WALLCLOCK_DALLAS_DS12887 current ;
package -hardware CYGPKG_DEVICES_WALLCLOCK_I386_PC current ;
package -template CYGPKG_HAL current ;
package -template CYGPKG_INFRA current ;
package -template CYGPKG_REDBOOT current ;
package -template CYGPKG_ISOINFRA current ;
package -template CYGPKG_LIBC_STRING current ;
package -template CYGPKG_CRC current ;
package CYGPKG_IO_ETH_DRIVERS current ;
};
cdl_option CYGFUN_LIBC_STRING_BSD_FUNCS {
inferred_value 0
};
cdl_option CYGIMP_HAL_COMMON_INTERRUPTS_USE_INTERRUPT_STACK {
inferred_value 0
};
cdl_option CYGNUM_HAL_COMMON_INTERRUPTS_STACK_SIZE {
user_value 4096
};
cdl_option CYGDBG_HAL_COMMON_INTERRUPTS_SAVE_MINIMUM_CONTEXT {
user_value 0
};
cdl_option CYGDBG_HAL_COMMON_CONTEXT_SAVE_MINIMUM {
user_value 0
inferred_value 0
};
cdl_option CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS {
inferred_value 1
};
cdl_option CYGSEM_HAL_ROM_MONITOR {
user_value 1
};
cdl_option CYGSEM_HAL_USE_ROM_MONITOR {
inferred_value 0 0
};
cdl_option CYGHWR_HAL_I386_FPU_SWITCH_LAZY {
inferred_value 0
};
cdl_component CYG_HAL_STARTUP {
user_value GRUB
};
cdl_option CYGNUM_HAL_VIRTUAL_VECTOR_CONSOLE_CHANNEL_BAUD {
user_value 115200
};
cdl_option CYGNUM_HAL_VIRTUAL_VECTOR_DEBUG_CHANNEL_BAUD {
user_value 115200
};
cdl_option CYGNUM_HAL_VIRTUAL_VECTOR_CONSOLE_CHANNEL_DEFAULT {
user_value 2
};
cdl_option CYGNUM_HAL_VIRTUAL_VECTOR_CONSOLE_CHANNEL {
user_value 2
};
cdl_component CYGPKG_HAL_I386_PCMB_MEMSIZE {
user_value GRUB
};
cdl_option CYGNUM_HAL_I386_PCMB_MEMSIZE_EXTENDED {
user_value 0x00100000
};
cdl_component CYGBLD_BUILD_REDBOOT {
user_value 1
};
cdl_component CYGDAT_REDBOOT_DEFAULT_IP_ADDR {
user_value 1 "192, 168, 25, 2"
};
cdl_option CYGSEM_REDBOOT_DEFAULT_NO_BOOTP {
user_value 1
};
cdl_option CYGSEM_REDBOOT_VALIDATE_USER_RAM_LOADS {
user_value 0
};
cdl_component CYGSEM_REDBOOT_BSP_SYSCALLS {
user_value 1
};
cdl_option CYGBLD_ISO_STRTOK_R_HEADER {
inferred_value 1 <cyg/libc/string/string.h>
};
cdl_option CYGBLD_ISO_STRING_LOCALE_FUNCS_HEADER {
inferred_value 1 <cyg/libc/string/string.h>
};
cdl_option CYGBLD_ISO_STRING_BSD_FUNCS_HEADER {
inferred_value 1 <cyg/libc/string/bsdstring.h>
};
cdl_option CYGBLD_ISO_STRING_MEMFUNCS_HEADER {
inferred_value 1 <cyg/libc/string/string.h>
};
cdl_option CYGBLD_ISO_STRING_STRFUNCS_HEADER {
inferred_value 1 <cyg/libc/string/string.h>
};
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss