This is the mail archive of the ecos-patches@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]
Other format: [Raw text]

Re: ISR/DSR without kernel present


Bob Koninckx <bob.koninckx@mech.kuleuven.ac.be> writes:

> On Wed, 2003-07-30 at 17:08, Nick Garnett wrote:
> > Bob Koninckx <bob.koninckx@mech.kuleuven.ac.be> writes:
> > 
> > > Hi all,
> > > 
> > > It seems that all infrastructure to use ISR/DSR handling in systems
> > > without a kernel is already present in drv-api.c. Some conditional
> > > compiles however seem to prevent things from getting used. The attached
> > > patches make Redboot handle interrupts flawlessly on the powerpc
> > > platform.
> > > 
> > 
> > These patches seem fine from the point of view of getting interrupts
> > to work in non-kernel configurations. It was always intended that this
> > be the case, but we have never had any applications to test it. So
> > bitrot has set in.
> > 
> > However, I do question your desire to make RedBoot handle interrupts.
> > RedBoot was explicitly designed to work with interrupts disabled since
> > trying to debug code while interrupts are firing can be very hard, and
> > depending on interrupts working in order to debug makes things very
> > fragile. Also, most applications want to handle their own interrupts
> > and will steal the interrupt vectors from RedBoot at startup.
> > 
> > So, what do you actually want RedBoot interrupts for?
> 
> Redboot is much more than just a debugger, isn't it ? I am implementing
> a bootp like functionality on top of the CAN/CANopen fieldbus, allowing
> our distributed motion controller to get its application software from
> the CAN bus rather than from flash. Getting this operational without
> interrupts might be possible but will certainly not be trivial.

I don't see why polling wouldn't work here. After all, we run an
entire TCP stack on top of polled device drivers. You just need to
make sure your polling code goes into the main redboot polling loop. A
bit of code and some CDL should deal with that.

But, of course, it's open source so you are free to do what you want!

> 
> After the application has booted there is no problem if it steals away
> interrupts from redboot, we'll never return to it anyway. Also debugging
> is no problem, we use BDM for that purpose.
> 
> Although I agree with your objections if you look at redboot primarily
> as a debug monitor, I still think that there are arguments for using
> interrupts, especially if you look at it as a bootloader.
>

Well, it has to be both. Breaking one part of its functionality is
fine if you really really are never going to use it. I wouldn't bet on
that though.

> As a sideline, using the hardware watchdog on the powerpc is near
> impossible if you can not use interrupts in redboot. I had a discussion
> with jifl on this subject not so long ago.
>

Ah, yes, I remember that too. That is probably a legitimate reason for
wanting to field some interrupts in RedBoot. My main concern is using
interrupts to operate the serial or ethernet devices. This is where
things can get very messy.


-- 
Nick Garnett                    eCos Kernel Architect
http://www.ecoscentric.com      The eCos and RedBoot experts


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