This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
RE: GDB connection via TCP
- To: Fabrice Gautier <Fabrice_Gautier at sdesigns dot com>
- Subject: RE: [ECOS] GDB connection via TCP
- From: Fabrice Gautier <Fabrice_Gautier at sdesigns dot com>
- Date: Mon, 23 Oct 2000 20:30:34 -0700
- Cc: "Ecos-List (E-mail)" <ecos-discuss at sourceware dot cygnus dot com>
Hi,
Okay, I have (in part) solve this problem (ie: I get the program running and
print output on gdb console) but among the output i get a lot of "Interrupt:
42"
Interrupt 42 is in fact the ethernet interrupt...
I know why: The interrupt is initially attached when redboot initialize the
hardware ethernet driver, but when the application (in RAM) is launched the
interrupt are re-attached to the default isr.
(The fact that the program still runs is probably because
In fact the code looks like:
#ifdef CYGPKG_KERNEL
{ int i ;
for (i = 0; i < CYGNUM_HAL_ISR_COUNT; i++)
HAL_INTERRUPT_ATTACH(i, (CYG_ADDRESS)hal_default_isr, 0,
0) ;
}
#endif /* CYGPKG_KERNEL */
so that Redboot will not initialise ISRs.
This would let think that the isr table are part of the kernel while some
driver would use it (without a kernel). Anyway the tables exist even if
there is no kernel (and there are some cyg_drv_interrupt_* functions to
handle it when there is no kernel).
I can see too that while the vsr table is (can be) shared between a rom
monitor and the application, the isr tables would be present in both.
So which tables would be used ?
In my case this is the application's table because when the ISR tables are
initialised (ie: attached to the default ISR) the VSR table is modified so
that the newly attached ISRs will effectively receive control.
I do not understand how this is handled with the assabet board which have
basically the same scenario with the ethernet driver in Redboot.
Thanks
--
Fabrice Gautier
fabrice_gautier@sdesigns.com
> -----Original Message-----
> From: Fabrice Gautier [mailto:Fabrice_Gautier@sdesigns.com]
> Subject: RE: [ECOS] GDB connection via TCP
>
> > -----Original Message-----
> > From: Gary Thomas [mailto:gthomas@redhat.com]
> > Subject: RE: [ECOS] GDB connection via TCP
> >
> > You need to make sure that these two values are defined in your CDL
> > CYGSEM_HAL_VIRTUAL_VECTOR_DIAG
> > CYGNUM_HAL_VIRTUAL_VECTOR_CONSOLE_CHANNEL_DEFAULT
> > Most likely, you don't have the latter. If these are not
> > both defined, then
> > the ethernet I/O can't work completely.
>
> The later was not present but this is not the main problem.
>
> The problem was/is that CYGPRI_HAL_IMPLEMENTS_IF_SERVICES was
> always defined
> because there was no CYGSEM_HAL_USE_ROM_MONITOR option.
>
> Now I added this one (copied from the assabet CDL) but I
> couldn't activate
> it because the RAM startup required to include the GDB Stub.
>
> I can indeed remove this dependency but in fact i'm not sure
> that's what I
> want to do. For If I remove the included gdb stub I loose he thread
> support...
>
> In fact I think that what I want to do is to use redboot only as the
> provider of the communications channels - particularly over TCP.
>
> How do you think this should be handled ?
>
>
> --
> Fabrice Gautier
> fabrice_gautier@sdesigns.com
>