RE: [ECOS] GDB connection via TCP

RE: [ECOS] GDB connection via TCP

[Fabrice Gautier]

> -----Original Message-----
> From: Gary Thomas [ mailto:gthomas@redhat.com ]
> Subject: RE: [ECOS] GDB connection via TCP
> 
> On 24-Oct-2000 Fabrice Gautier wrote:
> > I do not understand how this is handled with the assabet 
> > board which have
> > basically the same scenario with the ethernet driver in Redboot.
> > 
> 
> The main difference is that in the other environments, RedBoot runs in
> ROM which turns on CYGSEM_HAL_ROM_MONITOR which in turn 
> changes a number of internal behaviours.

As far as I can understand ARM assembly (which is not very far) it seems
that the VSR table entries are reinitialised by the RAM application (line
290 in vetors.S I think). 

It seems that in fact Redboot never enable IRQs but the ethernet card is
still configured to generate those IRQ so that when the real application is
started and interrupts enabled we get those spurious interrupts.

Why this would not occur with other board or arch is still a mistery for me.

Is there a way for Redboot to initialise the ethernet driver so that it
would not trigger interrupts ?

Thanks

-- 
Fabrice Gautier
fabrice_gautier@sdesigns.com 	

RE: [ECOS] GDB connection via TCP

[Gary Thomas]

On 24-Oct-2000 Fabrice Gautier wrote:
> I do not understand how this is handled with the assabet board which have
> basically the same scenario with the ethernet driver in Redboot.
> 

The main difference is that in the other environments, RedBoot runs in
ROM which turns on CYGSEM_HAL_ROM_MONITOR which in turn changes a number
of internal behaviours.

RE: [ECOS] GDB connection via TCP

[Fabrice Gautier]

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 
> 

RE: [ECOS] GDB connection via TCP

[Fabrice Gautier]

> -----Original Message-----
> From: Gary Thomas [ mailto:gthomas@redhat.com ]
> Sent: Monday, October 23, 2000 2:57 PM
> To: Fabrice Gautier
> Cc: Ecos-List (E-mail)
> 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 

RE: [ECOS] GDB connection via TCP

[Gary Thomas]

On 23-Oct-2000 Fabrice Gautier wrote:
> Hi,
> 
> When running RedBoot,  I can connect gdb via tcp or serial, I can load a
> program (serial or tcp work), and  I succeded running a test program but
> only with serial connection.
> 
> When I try to run the test program when connected with tcp, the program
> still try to do diag output via serial  but the output is O-packetized as if
> the program thought GDB was on serial.
> 
> In the redboot main, there is just before the breakpoint a
> CYGACC_CALL_IF_SET_CONSOLE_COMM(cur); but I don't know when/where 'cur' is
> updated. Anyway removing this line doesn't seem to change anything: serial
> works, tcp doesn't.
> 
> I'm wondering if the program itself have to set up the correct diag and/or
> debug channel when it uses te virtual vectors table ?

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.

[ECOS] GDB connection via TCP

[Fabrice Gautier]

Hi,

When running RedBoot,  I can connect gdb via tcp or serial, I can load a
program (serial or tcp work), and  I succeded running a test program but
only with serial connection.

When I try to run the test program when connected with tcp, the program
still try to do diag output via serial  but the output is O-packetized as if
the program thought GDB was on serial.

In the redboot main, there is just before the breakpoint a
CYGACC_CALL_IF_SET_CONSOLE_COMM(cur); but I don't know when/where 'cur' is
updated. Anyway removing this line doesn't seem to change anything: serial
works, tcp doesn't.

I'm wondering if the program itself have to set up the correct diag and/or
debug channel when it uses te virtual vectors table ?

Thanks

-- 
Fabrice Gautier
fabrice_gautier@sdesigns.com