[ECOS] RedBoot serial rx interrupts

[ECOS] RedBoot serial rx interrupts

[Grant Edwards]

I've got RedBoot running fine without network support.  It's
using polled serial I/O: the individual serial Rx interrupts
are unmasked but the global interrupt mask is set.  

[Why are interrupts being unmasked when polled I/O is being
used?]

When I add network support, the global interrupt mask is
cleared; cyg_hal_plf_serial_isr then consumes all of input
data.  RedBoot is still calling cyg_hal_plf_serial_getc() to
try to read input, but it never sees any because it's all being
consumed by the interrupt routine.

Can anybody point me to something that explains RedBoot's use
of interrupts?

Is the network stack interrupt driven?

Why does including network support clear the global interrupt
mask bit?

When is serial I/O interrupt driven?

-- 
Grant Edwards
grante@visi.com

RE: [ECOS] RedBoot serial rx interrupts

[Gary Thomas]

On 12-Jan-2001 Grant Edwards wrote:
> 
> I've got RedBoot running fine without network support.  It's
> using polled serial I/O: the individual serial Rx interrupts
> are unmasked but the global interrupt mask is set.  
> 
> [Why are interrupts being unmasked when polled I/O is being
> used?]
> 

It should not.  Where are you seeing this [which file/line]?

> When I add network support, the global interrupt mask is
> cleared; cyg_hal_plf_serial_isr then consumes all of input
> data.  RedBoot is still calling cyg_hal_plf_serial_getc() to
> try to read input, but it never sees any because it's all being
> consumed by the interrupt routine.
> 
> Can anybody point me to something that explains RedBoot's use
> of interrupts?
> 

RedBoot does not use interrupts.

> Is the network stack interrupt driven?
> 

RedBoot's stack does not.  eCos' does of course.

> Why does including network support clear the global interrupt
> mask bit?
> 

It does not - or should not - for RedBoot.

> When is serial I/O interrupt driven?
> 

Only when you use the serial I/O functions (serial_write, etc).

Are you sure about all of these questions?  RedBoot absolutely _never_
touches interrupts.  The only time interrupts are used is by eCos
applications.  

Re: [ECOS] RedBoot serial rx interrupts

[Grant Edwards]

On Sat, Jan 13, 2001 at 08:17:26AM -0700, Gary Thomas wrote:
> 
> On 12-Jan-2001 Grant Edwards wrote:
> > 
> > I've got RedBoot running fine without network support.  It's
> > using polled serial I/O: the individual serial Rx interrupts
> > are unmasked but the global interrupt mask is set.  
> > 
> > [Why are interrupts being unmasked when polled I/O is being
> > used?]
> > 
> 
> It should not.  Where are you seeing this [which file/line]?

hal/common/src/hal_if.c line 419 (at end of hal_ctrlc_isr_init()).

I suspect this appears to be happening because
CYGSEM_HAL_ROM_MONITOR == 0 (because CYG_HAL_STARTUP == RAM ?)

> Are you sure about all of these questions?  RedBoot absolutely _never_
> touches interrupts.  The only time interrupts are used is by eCos
> applications.  

I'm going to try to force CYGSEM_HAL_ROM_MONITOR to 1, to see
what happens.

I there a list of what the values for all of the configuration flags
need to be in order for RedBoot to work?

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] RedBoot serial rx interrupts

[Gary Thomas]

On 13-Jan-2001 Grant Edwards wrote:
> On Sat, Jan 13, 2001 at 08:17:26AM -0700, Gary Thomas wrote:
>> 
>> On 12-Jan-2001 Grant Edwards wrote:
>> > 
>> > I've got RedBoot running fine without network support.  It's
>> > using polled serial I/O: the individual serial Rx interrupts
>> > are unmasked but the global interrupt mask is set.  
>> > 
>> > [Why are interrupts being unmasked when polled I/O is being
>> > used?]
>> > 
>> 
>> It should not.  Where are you seeing this [which file/line]?
> 
> hal/common/src/hal_if.c line 419 (at end of hal_ctrlc_isr_init()).
> 
> I suspect this appears to be happening because
> CYGSEM_HAL_ROM_MONITOR == 0 (because CYG_HAL_STARTUP == RAM ?)
> 

You should _not_ have the options required to include this code set.
The options CYGDBG_HAL_DEBUG_GDB_BREAK_SUPPORT and CYGDBG_HAL_DEBUG_GDB_CTRLC_SUPPORT
should only be enabled for "normal" eCos applications.

>> Are you sure about all of these questions?  RedBoot absolutely _never_
>> touches interrupts.  The only time interrupts are used is by eCos
>> applications.  
> 
> I'm going to try to force CYGSEM_HAL_ROM_MONITOR to 1, to see
> what happens.
> 
> I there a list of what the values for all of the configuration flags
> need to be in order for RedBoot to work?

The best/simplest way is to use the template.
  % ecosconfig new PLATFORM redboot
  % ecosconfig tree

This will build a RAM based RedBoot, without any special drivers, for 
the given platform.  Once you have the pieces in place, you can add
FLASH and NET support like this:
  % ecosconfig add flash

  % ecosconfig add eth_drivers

Re: [ECOS] RedBoot serial rx interrupts

[Grant Edwards]

> >> It should not.  Where are you seeing this [which file/line]?
> > 
> > hal/common/src/hal_if.c line 419 (at end of hal_ctrlc_isr_init()).
> > 
> > I suspect this appears to be happening because
> > CYGSEM_HAL_ROM_MONITOR == 0 (because CYG_HAL_STARTUP == RAM ?)
> 
> You should _not_ have the options required to include this code set.
> The options CYGDBG_HAL_DEBUG_GDB_BREAK_SUPPORT and CYGDBG_HAL_DEBUG_GDB_CTRLC_SUPPORT
> should only be enabled for "normal" eCos applications.
>
> > I there a list of what the values for all of the configuration flags
> > need to be in order for RedBoot to work?
> 
> The best/simplest way is to use the template.
>   % ecosconfig new PLATFORM redboot
>   % ecosconfig tree

That is exactly what I'm doing:

$ ecosconfig new rpsh2 redboot   
U CYGHWR_HAL_ARM_BIGENDIAN, new inferred value 1
U CYGDBG_HAL_DEBUG_GDB_BREAK_SUPPORT, new inferred value 1
U CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS, new inferred value 1
U CYGDBG_HAL_DEBUG_GDB_CTRLC_SUPPORT, new inferred value 0
U CYGDBG_HAL_COMMON_CONTEXT_SAVE_MINIMUM, new inferred value 0

I guess there must be something wrong with my HAL cdl file.
I'll go back and compare it to one of the others.

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] RedBoot serial rx interrupts

[Grant Edwards]

On Sat, Jan 13, 2001 at 01:52:27PM -0700, Gary Thomas wrote:

> You should _not_ have the options required to include this code
> set. The options CYGDBG_HAL_DEBUG_GDB_BREAK_SUPPORT and
> CYGDBG_HAL_DEBUG_GDB_CTRLC_SUPPORT should only be enabled for
> "normal" eCos applications.
>
> > I there a list of what the values for all of the configuration
> > flags need to be in order for RedBoot to work?
> 
> The best/simplest way is to use the template.
>   % ecosconfig new PLATFORM redboot
>   % ecosconfig tree

I've tried a some other ARM targets (pid, edb7xxx, ebsa285),
and they all set CYGDBG_HAL_DEBUG_GDB_BREAK_SUPPORT and clear
CYGSEM_HAL_ROM_MONITOR (same as my HAL).  For example:

   $ ecosconfig new edb7xxx redboot
   U CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS, new inferred value 1
   U CYGSEM_HAL_USE_ROM_MONITOR, new inferred value 0
   U CYGDBG_HAL_COMMON_CONTEXT_SAVE_MINIMUM, new inferred value 0
   U CYGDBG_HAL_DEBUG_GDB_BREAK_SUPPORT, new inferred value 1
   U CYGDBG_HAL_DEBUG_GDB_CTRLC_SUPPORT, new inferred value 0

Would it be possible for somebody with a working RedBoot
configuration to give me a copy of their ecos.ecc file so I can
see what the values for all of the configuration flags are?

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] RedBoot serial rx interrupts

[Gary Thomas]

On 13-Jan-2001 Grant Edwards wrote:
> On Sat, Jan 13, 2001 at 01:52:27PM -0700, Gary Thomas wrote:
> 
>> You should _not_ have the options required to include this code
>> set. The options CYGDBG_HAL_DEBUG_GDB_BREAK_SUPPORT and
>> CYGDBG_HAL_DEBUG_GDB_CTRLC_SUPPORT should only be enabled for
>> "normal" eCos applications.
>>
>> > I there a list of what the values for all of the configuration
>> > flags need to be in order for RedBoot to work?
>> 
>> The best/simplest way is to use the template.
>>   % ecosconfig new PLATFORM redboot
>>   % ecosconfig tree
> 
> I've tried a some other ARM targets (pid, edb7xxx, ebsa285),
> and they all set CYGDBG_HAL_DEBUG_GDB_BREAK_SUPPORT and clear
> CYGSEM_HAL_ROM_MONITOR (same as my HAL).  For example:
> 
>    $ ecosconfig new edb7xxx redboot
>    U CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS, new inferred value 1
>    U CYGSEM_HAL_USE_ROM_MONITOR, new inferred value 0
>    U CYGDBG_HAL_COMMON_CONTEXT_SAVE_MINIMUM, new inferred value 0
>    U CYGDBG_HAL_DEBUG_GDB_BREAK_SUPPORT, new inferred value 1
>    U CYGDBG_HAL_DEBUG_GDB_CTRLC_SUPPORT, new inferred value 0
> 
> Would it be possible for somebody with a working RedBoot
> configuration to give me a copy of their ecos.ecc file so I can
> see what the values for all of the configuration flags are?

This looks OK and I think I mispoke before.  GDB_BREAK can and will
be set, even for RAM based RedBoot.

However, interrupts should never actually get turned on in the RedBoot
environment.  The only place where interrupts are enabled is in the
path where the kernel scheduler is enabled.

Are you seeing otherwise?  If so, where?

Re: [ECOS] RedBoot serial rx interrupts

[Grant Edwards]

On Sat, Jan 13, 2001 at 03:11:34PM -0700, Gary Thomas wrote:

> This looks OK and I think I mispoke before.  GDB_BREAK can and will
> be set, even for RAM based RedBoot.

Does that mean that it's normal for RedBoot to unmask serial
interrupts?

> However, interrupts should never actually get turned on in the
> RedBoot environment.  The only place where interrupts are
> enabled is in the path where the kernel scheduler is enabled.
> 
> Are you seeing otherwise?  If so, where?

My Ethernet driver initialization routine ends up calling
cyg_drv_isr_lock() and cyg_drv_isr_unlock().  The latter
enables interrupts.

I can add #defines to my driver code to turn those into noops
unless CYGPKG_NET is defined.

This raises the question: is it OK to call those two routines
during network device initialization?

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] RedBoot serial rx interrupts

[Gary Thomas]

On 13-Jan-2001 Grant Edwards wrote:
> On Sat, Jan 13, 2001 at 03:11:34PM -0700, Gary Thomas wrote:
> 
>> This looks OK and I think I mispoke before.  GDB_BREAK can and will
>> be set, even for RAM based RedBoot.
> 
> Does that mean that it's normal for RedBoot to unmask serial
> interrupts?
> 
>> However, interrupts should never actually get turned on in the
>> RedBoot environment.  The only place where interrupts are
>> enabled is in the path where the kernel scheduler is enabled.
>> 
>> Are you seeing otherwise?  If so, where?
> 
> My Ethernet driver initialization routine ends up calling
> cyg_drv_isr_lock() and cyg_drv_isr_unlock().  The latter
> enables interrupts.

Maybe we should improve this interface to return an indication of
whether the interrupts _were_ on when "isr_lock()" was called to
avoid this in the future.  I'll think about it.

> 
> I can add #defines to my driver code to turn those into noops
> unless CYGPKG_NET is defined.
> 
> This raises the question: is it OK to call those two routines
> during network device initialization?

It's not necessary.  Interrupts are always off during any system
initialization, so you could just leave this out [and feel safe].

Re: [ECOS] RedBoot serial rx interrupts

[Grant Edwards]

On Sat, Jan 13, 2001 at 04:13:47PM -0700, Gary Thomas wrote:

> > My Ethernet driver initialization routine ends up calling
> > cyg_drv_isr_lock() and cyg_drv_isr_unlock().  The latter
> > enables interrupts.
> 
> Maybe we should improve this interface to return an indication
> of whether the interrupts _were_ on when "isr_lock()" was
> called to avoid this in the future.  I'll think about it.

I doubt it's worth the extra overhead.

I hacked my way around the lock/unlock-during-init issue in
another kernel by statically initializing the lock counter to
its max value and then setting it to 0 just before the
scheduler first enables interrupts.  You'd still get interrupts
enabled during init if you called ulock() a lot of times
without calling lock(), but it behaved properly for balanced
lock/unlock calls.

> > I can add #defines to my driver code to turn those into noops
> > unless CYGPKG_NET is defined.
> > 
> > This raises the question: is it OK to call those two routines
> > during network device initialization?
> 
> It's not necessary.  Interrupts are always off during any
> system initialization, so you could just leave this out [and
> feel safe].

Right.  The situation arose because the init code called a
function that was also called by DSR and user-level code.  As
it turned out there just happened to be two versions of the
called function, one for use inside ISRs and one for "other".
Changing the init code to use the "ISR" version of the function
solved the problem.

But, to avoid future problems, I #defined a bunch of
cyg_drv_XXXX stuff to be noops when used for RedBoot.

It looks like things are working properly now (DHCP is working,
and I suspect that once I set up a TFTP server, that will
work).

I still have to use --ignore-errors so that I can have
CYGSEM_HAL_ROM_MONITOR==1 and CYG_HAL_STARTUP=="RAM".  I can
live with that, since my customers are going to be building
eCos apps but not RedBoot.

Thanks for the help (especially on a Saturday!)

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] RedBoot serial rx interrupts

[Nick Garnett]

Grant Edwards <grante@visi.com> writes:

> On Sat, Jan 13, 2001 at 04:13:47PM -0700, Gary Thomas wrote:
> 
> > > My Ethernet driver initialization routine ends up calling
> > > cyg_drv_isr_lock() and cyg_drv_isr_unlock().  The latter
> > > enables interrupts.
> > 
> > Maybe we should improve this interface to return an indication
> > of whether the interrupts _were_ on when "isr_lock()" was
> > called to avoid this in the future.  I'll think about it.
> 
> I doubt it's worth the extra overhead.
> 
> I hacked my way around the lock/unlock-during-init issue in
> another kernel by statically initializing the lock counter to
> its max value and then setting it to 0 just before the
> scheduler first enables interrupts.  You'd still get interrupts
> enabled during init if you called ulock() a lot of times
> without calling lock(), but it behaved properly for balanced
> lock/unlock calls.
> 

This looks like a bug in drv_api.c. the isr_disable_counter variable
should be initialized to 1 - indicating that the interrupts start off
disabled. Then any lock/unlock pairs will keep interrupts masked.
The equivalent variable in the kernel is initialized to 1.

Until RedBoot came along a lot of this code wasn't being exercised
much, so nobody noticed that this had not been kept up to date with
the kernel.

I'll fix this in our CVS tree, and it should filter out to anoncvs
with the next update.


-- 
Nick Garnett, eCos Kernel Architect
Red Hat, Cambridge, UK