This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: GDB connection via TCP


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 
> 

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]