[ECOS] i386 TARGET network programming

[ECOS] i386 TARGET network programming

[Trenton D. Adams]

I already sent a message like this to the list from my other email
address.  However, since I sent it on Saturday, and I haven't received
it back from the list yet, I assume it didn't get through.

I'm wondering if the only network adapter I can use for network
programming is that Intel Etherexpress Pro or whatever it is?  If so,
what is the i386 target for?  If I don't have networking capability it
seems that it would be a waste of time for anything else.  I can't think
of anything else that someone might use it for.

Or, does RedBoot only support that network card?  If it's only a redboot
limitation, I can live with that.


Trenton D. Adams
Embedded Developer
Windows Developer
Extreme Engineering Ltd.
Calgary Alberta

Phone: 403 640 9494 ext 208
Fax:   403 640 9599

Re: [ECOS] i386 TARGET network programming

[Jonathan Larmour]

"Trenton D. Adams" wrote:
> 
> I already sent a message like this to the list from my other email
> address.  However, since I sent it on Saturday, and I haven't received
> it back from the list yet, I assume it didn't get through.
> 
> I'm wondering if the only network adapter I can use for network
> programming is that Intel Etherexpress Pro or whatever it is?  If so,
> what is the i386 target for?  If I don't have networking capability it
> seems that it would be a waste of time for anything else.  I can't think
> of anything else that someone might use it for.

There's plenty of PC compatible motherboards that people use for embedded
applications. Not every embedded application requires networking abilities,
and not everyone specifically needs to use a specific card, so an Intel
Etherexpress compatible card is adequate. Although, if you like, just
earlier Rosimildo da Silva just made available a 3Com 3c5x9 NIC driver.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

RE: [ECOS] i386 TARGET network programming

[Trenton D. Adams]

  > 
  > "Trenton D. Adams" wrote:
  > >
  > > I already sent a message like this to the list from my other email
  > > address.  However, since I sent it on Saturday, and I haven't
received
  > > it back from the list yet, I assume it didn't get through.
  > >
  > > I'm wondering if the only network adapter I can use for network
  > > programming is that Intel Etherexpress Pro or whatever it is?  If
so,
  > > what is the i386 target for?  If I don't have networking
capability it
  > > seems that it would be a waste of time for anything else.  I can't
  > think
  > > of anything else that someone might use it for.
  > 
  > There's plenty of PC compatible motherboards that people use for
  > embedded
  > applications. Not every embedded application requires networking
  > abilities,
  > and not everyone specifically needs to use a specific card, so an
Intel
  > Etherexpress compatible card is adequate. Although, if you like,
just
  > earlier Rosimildo da Silva just made available a 3Com 3c5x9 NIC
driver.
  > 

Unfortunately, I don't own either one of the cards.

Are there any cards out there that would use the same driver as the
Intel Etherexpress?  I need a 10/100 card for my other machine anyhow so
I could just buy one of those.  I don't want to pay out the $70+ for a
3COM or $120+ for the Intel card.

Re: [ECOS] i386 TARGET network programming

[Jonathan Larmour]

"Trenton D. Adams" wrote:
> 
> Unfortunately, I don't own either one of the cards.

There's always the option of writing a new driver :-).
 
> Are there any cards out there that would use the same driver as the
> Intel Etherexpress?

Probably, it's the i82559 chipset.

> I need a 10/100 card for my other machine anyhow so
> I could just buy one of those.  I don't want to pay out the $70+ for a
> 3COM or $120+ for the Intel card.

I just remembared: there's an NE2000 driver by Christian Plessl and Thomas
Meyer listed at http://sources.redhat.com/ecos/contrib.html which we
couldn't incorporate for copyright reasons. NE2K cards are a lot cheaper.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

RE: [ECOS] i386 TARGET network programming

[Trenton D. Adams]

  > 
  > "Trenton D. Adams" wrote:
  > >
  > > Unfortunately, I don't own either one of the cards.
  > 
  > There's always the option of writing a new driver :-).
  > 
  > > Are there any cards out there that would use the same driver as
the
  > > Intel Etherexpress?
  > 
  > Probably, it's the i82559 chipset.
  > 
  > > I need a 10/100 card for my other machine anyhow so
  > > I could just buy one of those.  I don't want to pay out the $70+
for a
  > > 3COM or $120+ for the Intel card.
  > 
  > I just remembared: there's an NE2000 driver by Christian Plessl and
  > Thomas
  > Meyer listed at http://sources.redhat.com/ecos/contrib.html which we
  > couldn't incorporate for copyright reasons. NE2K cards are a lot
  > cheaper.
  > 

So, if ne.o in linux works with the card, then the eCos driver should as
well right?

Is there anyway of getting eCos to query the drivers in linux for
network capability?  If so, I imagine it would be a lot of work right?

Re: [ECOS] i386 TARGET network programming

[Jonathan Larmour]

"Trenton D. Adams" wrote:
>   > I just remembared: there's an NE2000 driver by Christian Plessl and
>   > Thomas
>   > Meyer listed at http://sources.redhat.com/ecos/contrib.html which we
>   > couldn't incorporate for copyright reasons. NE2K cards are a lot
>   > cheaper.
>   >
> 
> So, if ne.o in linux works with the card, then the eCos driver should as
> well right?

I wouldn't go as far as that :-). I'd say if ne.o in Linux doesn't work,
the eCos driver probably won't either :-). I should also mention that there
may be a little bitrot in the driver.
 
> Is there anyway of getting eCos to query the drivers in linux for
> network capability?  If so, I imagine it would be a lot of work right?

Ummm... given they are completely different OS's, I don't really know what
you mean here. This isn't the synthetic target if that's what you're
thinking about.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

RE: [ECOS] i386 TARGET network programming

[Trenton D. Adams]

  > 
  > > Is there anyway of getting eCos to query the drivers in linux for
  > > network capability?  If so, I imagine it would be a lot of work
right?
  > 
  > Ummm... given they are completely different OS's, I don't really
know
  > what
  > you mean here. This isn't the synthetic target if that's what you're
  > thinking about.
  > 

From what I understand, don't eCos PC target programs run directly as
native Linux executables running an eCos OS which call on the Linux
kernel for various aspects of the eCos kernel?  I was sure I read that
somewhere.   If so, can't a network driver be written that will do a
similar thing to gain access to all possible network card drivers under
linux?

Re: [ECOS] i386 TARGET network programming

[Jonathan Larmour]

"Trenton D. Adams" wrote:
> 
>   >
>   > > Is there anyway of getting eCos to query the drivers in linux for
>   > > network capability?  If so, I imagine it would be a lot of work
> right?
>   >
>   > Ummm... given they are completely different OS's, I don't really
> know
>   > what
>   > you mean here. This isn't the synthetic target if that's what you're
>   > thinking about.
>   >
> 
> >From what I understand, don't eCos PC target programs run directly as
> native Linux executables running an eCos OS which call on the Linux
> kernel for various aspects of the eCos kernel?

That's the "synthetic Linux" target. The (real) PC target is a proper port
to PCs, which you can boot off a floppy, or with the right support, even
program into flash.

>  I was sure I read that
> somewhere.   If so, can't a network driver be written that will do a
> similar thing to gain access to all possible network card drivers under
> linux?

Yes, but only the synthetic linux target :).

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

RE: [ECOS] i386 TARGET network programming

[Trenton D. Adams]

  > 
  > "Trenton D. Adams" wrote:
  > >
  > >   >
  > >   > > Is there anyway of getting eCos to query the drivers in
linux
  > for
  > >   > > network capability?  If so, I imagine it would be a lot of
work
  > > right?
  > >   >
  > >   > Ummm... given they are completely different OS's, I don't
really
  > > know
  > >   > what
  > >   > you mean here. This isn't the synthetic target if that's what
  > you're
  > >   > thinking about.
  > >   >
  > >
  > > >From what I understand, don't eCos PC target programs run
directly as
  > > native Linux executables running an eCos OS which call on the
Linux
  > > kernel for various aspects of the eCos kernel?
  > 
  > That's the "synthetic Linux" target. The (real) PC target is a
proper
  > port
  > to PCs, which you can boot off a floppy, or with the right support,
even
  > program into flash.
  > 
  > >  I was sure I read that
  > > somewhere.   If so, can't a network driver be written that will do
a
  > > similar thing to gain access to all possible network card drivers
  > under
  > > linux?
  > 
  > Yes, but only the synthetic linux target :).
  > 

Oh, I see, thanks!  I'm going to ask a quick question about that in a
minute if I can't find it in the archives.

Re: [ECOS] i386 TARGET network programming

[Fabrice Gautier]

On Mon, 30 Jul 2001 13:13:42 -0600
"Trenton D. Adams" <tadams@extremeeng.com> wrote:

>> and not everyone specifically needs to use a specific card, so an
>> Etherexpress compatible card is adequate. Although, if you like,
>> earlier Rosimildo da Silva just made available a 3Com 3c5x9 NIC
>> driver.
>   > 
> 
> Unfortunately, I don't own either one of the cards.

There also a driver for NE2000 cards, see http://sources.redhat.com/ecos/contrib.html
I've not tested it but anyway this could be a good start.

And NE2000 cards are the cheapest you can find.


-- 
Fabrice Gautier <gautier@email.enstfr>

RE: [ECOS] i386 TARGET network programming

[Trenton D. Adams]

  > 
  > That's the "synthetic Linux" target. The (real) PC target is a
proper
  > port
  > to PCs, which you can boot off a floppy, or with the right support,
even
  > program into flash.
  > 
  > >  I was sure I read that
  > > somewhere.   If so, can't a network driver be written that will do
a
  > > similar thing to gain access to all possible network card drivers
  > under
  > > linux?
  > 
  > Yes, but only the synthetic linux target :).
  > 

Is this a Yes for yes, it could be done, or Yes, it's already been done!
:)

Re: [ECOS] i386 TARGET network programming

[Jonathan Larmour]

"Trenton D. Adams" wrote:
> Is this a Yes for yes, it could be done, or Yes, it's already been done!
> :)

There are some old patches that maybe Bart can tell you about that may have
this. But there's nothing really available right now. It probably wouldn't
be terribly difficult though. But there would have to be a program
somewhere running as root allowing access to the raw ethernet frames if you
wanted it to be a decent "emulation".

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

[ECOS] RM7000 interrupt handling

[Chris Morrow]

For the mips architecture HAL_INTERRUPT_MASK is defined as
follows;

#define HAL_INTERRUPT_MASK( _vector_ )          \
CYG_MACRO_START                                 \
    asm volatile (                              \
        "mfc0   $3,$12\n"                       \
        "la     $2,0x00000400\n"                \
        "sllv   $2,$2,%0\n"                     \
        "nor    $2,$2,$0\n"                     \
        "and    $3,$3,$2\n"                     \
        "mtc0   $3,$12\n"                       \
        "nop; nop; nop\n"                       \
        :                                       \
        : "r"(_vector_)                         \
        : "$2", "$3"                            \
        );                                      \
CYG_MACRO_END

It is possible to get an interrupt between the mfco and mtco.
As long as the status register is not modified as part of
interrupt processing this is not a problem.

Recently the following was added at the end of
_default_interrupt handler in vectors.S
#ifndef CYG_HAL_MIPS_R3900	
	# Keep the current settings of the IM[7:0] bits within the status
	# register.  These may be used as interrupt masks, so if an ISR or
	# DSR masks interrupts they must be preserved.
	# If they are not used, then this does no harm.
	ori	k0,zero,0xff00
	nor	k0,k0,k0			# 0xffff00ff
	and	k1,k1,k0			# all interrupts disabled

	mfc0	k0,status			# V0 = current SR
	nop
	nop
	andi	k0,k0,0xff00			# preserve interrupt set
	or	k1,k1,k0			# insert into "saved SR"
#endif

Consider the following scenario;

Suppose status register has interrupts 1 & 2 are unmasked
- first half of HAL_INTERRUPT_MASK for interrupt 1 is executed,
  r3 has copy of status register with 1 & 2 masked
- interrupt 2 occurs
- ISR masks off interrupt 2 in status register
- interrupt returns; status register has interrupt 1 unmasked
- second half of HAL_INTERRUPT_MASK executes; r3 has interrupt
  1 masked, 2 is still unmasked. r3 is copied to status register.

We have just lost the masking of interrupt 2.

Does this make sense to people?


-- 
Chris Morrow	YottaYotta Inc. email: cmorrow@yottayotta.com
phone: (780) 989 6814 web:	http:  //www.yottayotta.com

Re: [ECOS] i386 TARGET network programming

[Fabrice Gautier]

On Mon, 30 Jul 2001 20:20:11 +0100
Jonathan Larmour <jlarmour@redhat.com> wrote:

> 
> there's an NE2000 driver [...] which we
> couldn't incorporate for copyright reasons.

How come?

The webpage says that it come from OpenBLT, which according to their
license seems compatible with eCos license. (it looks pretty much like a BSD
license)



-- 
Fabrice Gautier <gautier@email.enstfr>

Re: [ECOS] RM7000 interrupt handling

[Hugo Tyson]

Chris Morrow <cmorrow@YottaYotta.com> writes:
> For the mips architecture HAL_INTERRUPT_MASK is defined as
> follows;
> 
> #define HAL_INTERRUPT_MASK( _vector_ )          \
> CYG_MACRO_START                                 \
>     asm volatile (                              \
>         "mfc0   $3,$12\n"                       \
>         "la     $2,0x00000400\n"                \
>         "sllv   $2,$2,%0\n"                     \
>         "nor    $2,$2,$0\n"                     \
>         "and    $3,$3,$2\n"                     \
>         "mtc0   $3,$12\n"                       \
>         "nop; nop; nop\n"                       \
>         :                                       \
>         : "r"(_vector_)                         \
>         : "$2", "$3"                            \
>         );                                      \
> CYG_MACRO_END
> 
> It is possible to get an interrupt between the mfco and mtco.
> As long as the status register is not modified as part of
> interrupt processing this is not a problem.

Right.  But that can happen, and I agree that you have found a bug.

But for many [all?] platforms those macros in the arch HAL are not used;
the variant or platform HAL supplies them, because the platform has an
external PIC or some other mask register for additional interrupt sources.

Looks like some MIPS platforms, but not all, have a similar bug. ;-(

	- Huge

Re: [ECOS] RM7000 interrupt handling

[Mark Salter]

>>>>> Hugo Tyson writes:

> Chris Morrow <cmorrow@YottaYotta.com> writes:
>> For the mips architecture HAL_INTERRUPT_MASK is defined as
>> follows;
>> 
>> #define HAL_INTERRUPT_MASK( _vector_ )          \
>> CYG_MACRO_START                                 \
>> asm volatile (                              \
>> "mfc0   $3,$12\n"                       \
>> "la     $2,0x00000400\n"                \
>> "sllv   $2,$2,%0\n"                     \
>> "nor    $2,$2,$0\n"                     \
>> "and    $3,$3,$2\n"                     \
>> "mtc0   $3,$12\n"                       \
>> "nop; nop; nop\n"                       \
>> :                                       \
>> : "r"(_vector_)                         \
>> : "$2", "$3"                            \
>> );                                      \
>> CYG_MACRO_END
>> 
>> It is possible to get an interrupt between the mfco and mtco.
>> As long as the status register is not modified as part of
>> interrupt processing this is not a problem.

> Right.  But that can happen, and I agree that you have found a bug.

> But for many [all?] platforms those macros in the arch HAL are not used;
> the variant or platform HAL supplies them, because the platform has an
> external PIC or some other mask register for additional interrupt sources.

> Looks like some MIPS platforms, but not all, have a similar bug. ;-(

I think the bug would be an ISR that changes the status register.

There is no atomic way of disabling interrupts on the MIPS architecture.
You have to read the status register, modify it, then write it back.

--Mark

Re: [ECOS] RM7000 interrupt handling

[Robin Farine]

Mark Salter <msalter@redhat.com> writes:

[...]

> I think the bug would be an ISR that changes the status register.
> 
> There is no atomic way of disabling interrupts on the MIPS architecture.
> You have to read the status register, modify it, then write it back.

If I remember well, the restrictions below avoid such problems:

1. the startup code presets the per-source interrupt bits and they never change
   after that; code should use the devices internal interrupt controllers to
   enable/disable interrupt sources.

2. the interrupt VSR and ISRs use the master interrupt bit only => no nested
   interrupts

3. the rest of the code can safely disable and restore interrupts using the
   master interrupt bit only;

What do you think, too much restrictive for eCos?

Robin

Re: [ECOS] RM7000 interrupt handling

[Hugo Tyson]

> From: Robin Farine <acnrf@dial.eunet.ch>
> Mark Salter <msalter@redhat.com> writes:
> 
> [...]
> 
> > I think the bug would be an ISR that changes the status register.
> > 
> > There is no atomic way of disabling interrupts on the MIPS architecture.
> > You have to read the status register, modify it, then write it back.
> 
> If I remember well, the restrictions below avoid such problems:
> 
> 1. the startup code presets the per-source interrupt bits and they never change
>    after that; code should use the devices internal interrupt controllers to
>    enable/disable interrupt sources.
> 
> 2. the interrupt VSR and ISRs use the master interrupt bit only => no nested
>    interrupts
> 
> 3. the rest of the code can safely disable and restore interrupts using the
>    master interrupt bit only;

You remember well, I think.

Yes, those conditions would fix the situation - I think that (1.) and (3.)
alone (ie. VSRs and ISRs don't diddle the interrupt bit at all) would be
OK, ISRs must use only the method in (1.)
 
> What do you think, too much restrictive for eCos?

Sadly I do think that; we want HAL_MASK_INTERRUPTS() et al to work!  Having
them be a NOP for the low range of interrupt numbers would be, um, awkward?

We don't want the HAL to have to know about the Ethernet hardware details,
for example, if you're not including the ethernet package; but it would
need to know about the ether control regs to mask its interrupt outside of
the status register.

I'll continue having a think about this and see what we come up with.

	- Huge

Re: [ECOS] RM7000 interrupt handling

[Robin Farine]

Hugo Tyson <hmt@redhat.com> writes:

[...]

> > 
> > 1. the startup code presets the per-source interrupt bits and they never change
> >    after that; code should use the devices internal interrupt controllers to
> >    enable/disable interrupt sources.
> > 
> > 2. the interrupt VSR and ISRs use the master interrupt bit only => no nested
> >    interrupts
> > 
> > 3. the rest of the code can safely disable and restore interrupts using the
> >    master interrupt bit only;
> 
> You remember well, I think.
> 
> Yes, those conditions would fix the situation - I think that (1.) and (3.)
> alone (ie. VSRs and ISRs don't diddle the interrupt bit at all) would be
> OK, ISRs must use only the method in (1.)

Yes right, the ISRs don't but the VSR has to reenable interrupts for the DSRs,
no?

>  
> > What do you think, too much restrictive for eCos?
> 
> Sadly I do think that; we want HAL_MASK_INTERRUPTS() et al to work!  Having
> them be a NOP for the low range of interrupt numbers would be, um, awkward?

Wouldn't it be suffiscient if they only use the master bit? Why would the
common, device independent code touch the other bits whose meaning is platform
dependent anyway (the software interrupts excepted)?

> We don't want the HAL to have to know about the Ethernet hardware details, for
> example, if you're not including the ethernet package; but it would need to
> know about the ether control regs to mask its interrupt outside of the status
> register.

Yeah, but the device's ISR knows about the device and thus can disable the
device interrupts, and the associated DSR reenables them.

> 
> I'll continue having a think about this and see what we come up with.
> 
> 	- Huge

Re: [ECOS] RM7000 interrupt handling

[Chris Morrow]

On the RM7000, the info register contains a bit which allows for the
atomic enabling and disabling of interrupts. HAL_MASK_INTERRUPTS()
can be made to work using this. I'm not familiar enough with
other mips platforms to know how widely this kind of thing is
implemented.

On what may be a related subject, I've never understood the reason
for cyg_drv_interrupt_mask. Every eCos post seems to just map this
to cyg_interrupt_mask. Was the orignal intent to mask off interrupts
at the device instead of the CPU?


Hugo Tyson wrote:
> 
> > From: Robin Farine <acnrf@dial.eunet.ch>
> > Mark Salter <msalter@redhat.com> writes:
> >
> > [...]
> >
> > > I think the bug would be an ISR that changes the status register.
> > >
> > > There is no atomic way of disabling interrupts on the MIPS architecture.
> > > You have to read the status register, modify it, then write it back.
> >
> > If I remember well, the restrictions below avoid such problems:
> >
> > 1. the startup code presets the per-source interrupt bits and they never change
> >    after that; code should use the devices internal interrupt controllers to
> >    enable/disable interrupt sources.
> >
> > 2. the interrupt VSR and ISRs use the master interrupt bit only => no nested
> >    interrupts
> >
> > 3. the rest of the code can safely disable and restore interrupts using the
> >    master interrupt bit only;
> 
> You remember well, I think.
> 
> Yes, those conditions would fix the situation - I think that (1.) and (3.)
> alone (ie. VSRs and ISRs don't diddle the interrupt bit at all) would be
> OK, ISRs must use only the method in (1.)
> 
> > What do you think, too much restrictive for eCos?
> 
> Sadly I do think that; we want HAL_MASK_INTERRUPTS() et al to work!  Having
> them be a NOP for the low range of interrupt numbers would be, um, awkward?
> 
> We don't want the HAL to have to know about the Ethernet hardware details,
> for example, if you're not including the ethernet package; but it would
> need to know about the ether control regs to mask its interrupt outside of
> the status register.
> 
> I'll continue having a think about this and see what we come up with.
> 
>         - Huge

-- 
Chris Morrow	YottaYotta Inc. email: cmorrow@yottayotta.com
phone: (780) 989 6814 web:	http:  //www.yottayotta.com

Re: [ECOS] RM7000 interrupt handling

[Hugo Tyson]

Chris Morrow <cmorrow@YottaYotta.com> writes:
> On the RM7000, the info register contains a bit which allows for the
> atomic enabling and disabling of interrupts. HAL_MASK_INTERRUPTS()
> can be made to work using this. I'm not familiar enough with
> other mips platforms to know how widely this kind of thing is
> implemented.
> 
> On what may be a related subject, I've never understood the reason
> for cyg_drv_interrupt_mask. Every eCos port seems to just map this
> to cyg_interrupt_mask.

Yes, they all do - /if/ there is a kernel present, you only have
cyg_interrupt_mask() from the KAPI if you have the kernel.  If not it
simply does HAL_INTERRUPT_MASK( vector ), which will mask the interrupt on
that vector number.

>  Was the orignal intent to mask off interrupts at the device instead of
> the CPU?

Nope.

It's to allow the same device driver code (hence _drv_ in the names) to
work with and without a kernel.  The kernel might do different and clever
things when masking an interrupt, depending on the interrupt decoding or
chaining or sharing or whatever scheme is in place.  So if there is a
kernel, there is benefit in calling it.

To be honest, in most cases, just calling HAL_INTERRUPT_MASK( vector ) thus
going directly into the HAL layer would work perfectly well, without all
those function calls through the KAPI and so on.  But that breaks all the
lovely abstraction layers ;-/ and it's not an API that we promise to
support for application code, hence the provision of the other APIs.

HTH,
	- Huge

Re: [ECOS] i386 TARGET network programming

[Jonathan Larmour]

Fabrice Gautier wrote:
> 
> On Mon, 30 Jul 2001 20:20:11 +0100
> Jonathan Larmour <jlarmour@redhat.com> wrote:
> 
> >
> > there's an NE2000 driver [...] which we
> > couldn't incorporate for copyright reasons.
> 
> How come?
> 
> The webpage says that it come from OpenBLT, which according to their
> license seems compatible with eCos license. (it looks pretty much like a BSD
> license)

There is one key problem: it contains the (so-called) "advertising clause"
which BSD later removed. This is clause 2 in that licence. This would bind
everyone who uses the driver in a product. So while we are happy to
distribute it on our web site, we aren't happy to include it in the main
source distribution itself.

Although I haven't approached Brian Swetland about this to see if he would
be willing to waive this clause.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

Re: [ECOS] i386 TARGET network programming

[Jonathan Larmour]

Jonathan Larmour wrote:
> 
> There is one key problem: it contains the (so-called) "advertising clause"
> which BSD later removed. This is clause 2 in that licence. This would bind
> everyone who uses the driver in a product. So while we are happy to
> distribute it on our web site, we aren't happy to include it in the main
> source distribution itself.

Now this is interesting: our BSD stack still claims to have the advertising
clause even though it should have been removed. I'll have to check up on
this....

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

Re: [ECOS] i386 TARGET network programming

[Jonathan Larmour]

Jonathan Larmour wrote:
> 
> Jonathan Larmour wrote:
> >
> > There is one key problem: it contains the (so-called) "advertising clause"
> > which BSD later removed. This is clause 2 in that licence. This would bind
> > everyone who uses the driver in a product. So while we are happy to
> > distribute it on our web site, we aren't happy to include it in the main
> > source distribution itself.
> 
> Now this is interesting: our BSD stack still claims to have the advertising
> clause even though it should have been removed. I'll have to check up on
> this....

Nope, I'm talking rubbish... the advertising clause is _this_ one which our
sources do not include:

 * 3. All advertising materials mentioning features or use of this software
 *    must display the following acknowledgement:
 *      This product includes software developed by the University of
 *      California, Berkeley and its contributors.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

Re: [ECOS] i386 TARGET network programming

[Fabrice Gautier]

On Tue, 31 Jul 2001 22:44:53 +0100
Jonathan Larmour <jlarmour@redhat.com> wrote:

> Jonathan Larmour wrote:
> > 
> > Jonathan Larmour wrote:
> > >
> > > There is one key problem: it contains the (so-called) "advertising clause"
> > > which BSD later removed. 

OK, and anyway, i've loked at openBLT sources, in particular the
ne2000.c file (which is probably the basefor the eCos driver). 

This file contains the following note:

// derived from National Semiconductor datasheets and application notes
// as well as the Linux driver by Donald Becker */

Which should make it GPL...



-- 
Fabrice Gautier <gautier@email.enstfr>

Re: [ECOS] i386 TARGET network programming

[Jonathan Larmour]

Fabrice Gautier wrote:
> i've loked at openBLT sources, in particular the
> ne2000.c file (which is probably the basefor the eCos driver).
> 
> This file contains the following note:
> 
> // derived from National Semiconductor datasheets and application notes
> // as well as the Linux driver by Donald Becker */
> 
> Which should make it GPL...

Possibly but not necessarily - if it was only used for reading as a
reference it should be alright. If code was actually taken from it, then
that would be fatal.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

Re: [ECOS] RM7000 interrupt handling

[Hugo Tyson]

We were discussing the eCos requirement of being able to mask individual
interrupt sources within an ISR, and the difficulty in doing that in MIPS
variants where the individual mask bits are in the SR along with the global
"disable interrupts" bit.  There's always a race condition in the
read-modify-write op that's needed to disable all interrupts.

Chris Morrow <cmorrow@YottaYotta.com> spotted that race condition in
conseqence of looking at the code I added to allow ISR changes to the SR to
"stick" when the interrupt returns, so thanks Chris, you saved us some
possibly painful and elongated debugging!

There is a neat enough solution, which I have implemented in the target we
have that does have individual mask bits in the SR.

We need to keep a shadow copy of the SR mask bits in RAM, and the RAM copy
is the truth.  The race condition in HAL_DISABLE_INTERRUPTS() is avoided by
disabling interrupts as before, and then, *once interrupts are disabled*
reading the RAM copy and injecting it into the SR.  That way, even if an
ISR's manipulation of the SR bits is discarded, the RAM copy still holds
and is poked into the SR.  HAL_RESTORE_INTERRUPTS() also injects the true
value.  The RAM copy needs to be at a fixed memory location so that it is
shared with RedBoot, since intercalling between the app and RedBoot can
enable and disable the interrupts on the debug channel, which can only work
correctly if the same RAM copy is used in both contexts.  That's dealt with
in the linker script which places hal_interrupt_sr_mask_shadow_base[].

Anyway, there are some minor changes to the MIPS arch HAL to allow the
variant to define HAL_DISABLE_INTERRUPTS() et al, they'll be out in anoncvs
soon.  The variant HAL is not (yet) published, so I'll put the snippets of
code from the variant HAL's var_intr.h on the end of this message to help
anyone else who's dealing with the same issues.

        - Huge

---------------------------------------------------------------------------

// This is placed in memory at a fixed location because we must share it
// with RedBoot, along with the VSR table and Virtual Vector table.
// It has to be an array to get the correct code generation to access it
// over all that distance.

externC volatile cyg_uint32 hal_interrupt_sr_mask_shadow_base[];

#define hal_interrupt_sr_mask_shadow (hal_interrupt_sr_mask_shadow_base[0])

// We have to have local versions of these to preserve the mask bits in the
// SR correctly when an interrupt occurs within one of these code sequences
// which are doing a read-modify-write to the main interrupt bit of the SR.

// Disable, it doesn't matter what the SR IM bits are - but it is possible
// for control to return with interrupts enabled if a context switch occurs
// away from the thread that disabled interrupts.  Therefore we also make
// sure the contents of the SR match the shadow variable at the end.

#define HAL_DISABLE_INTERRUPTS(_old_)                                   \
CYG_MACRO_START                                                         \
    register int _tmp;                                                  \
    asm volatile (                                                      \
        "mfc0   $8,$12; nop;"                                           \
        "move   %0,$8;"                                                 \
        "and    $8,$8,0xfffffffe;"                                      \
        "mtc0   $8,$12;"                                                \
        "nop; nop; nop;"                                                \
        : "=r"(_tmp)                                                    \
        :                                                               \
        : "$8"                                                          \
        );                                                              \
    /* interrupts disabled so can now inject the correct IM bits */     \
    (_old_) = _tmp & 1;                                                 \
    _tmp &= 0xffff00fe;                                                 \
    _tmp |= (hal_interrupt_sr_mask_shadow & 0xff00);                    \
    asm volatile (                                                      \
        "mtc0   %0,$12;"                                                \
        "nop; nop; nop;"                                                \
        :                                                               \
        : "r"(_tmp)                                                     \
        );                                                              \
CYG_MACRO_END

// Enable and restore, we must pick up hal_interrupt_sr_mask_shadow because
// it contains the truth.  This is also for the convenience of the
// mask/unmask macros below.
#define HAL_ENABLE_INTERRUPTS() HAL_RESTORE_INTERRUPTS(1)

#define HAL_RESTORE_INTERRUPTS(_old_)                                   \
CYG_MACRO_START                                                         \
    asm volatile (                                                      \
        "mfc0   $8,$12; nop;"                                           \
        "or     $8,$8,%0;"         /* inject IE bit  */                 \
        "and    $8,$8,0xffff00ff;" /* clear IM bits  */                 \
        "or     $8,$8,%1;"         /* insert true IM */                 \
        "mtc0   $8,$12;"                                                \
        "nop; nop; nop;"                                                \
        :                                                               \
        : "r"((_old_) & 1),"r"(hal_interrupt_sr_mask_shadow & 0xff00)   \
        : "$8"                                                          \
        );                                                              \
CYG_MACRO_END

#define CYGHWR_HAL_INTERRUPT_ENABLE_DISABLE_RESTORE_DEFINED

// ------------------------------------------------------------------------

// For the bits which are in the SR, we only need to diddle the shadow
// variable; restore interrupts will pick that up at the end of the macro.

#define HAL_INTERRUPT_MASK( _vector_ )                                  \
CYG_MACRO_START                                                         \
register int _intstate;                                                 \
register int _shift;                                                    \
HAL_DISABLE_INTERRUPTS( _intstate );                                    \
if ( CYGNUM_HAL_INTERRUPT_SYSCTL_LOW > (_vector_) ) {                   \
    /* mask starts at bit 8 */                                          \
    _shift = 8 + (_vector_) - CYGNUM_HAL_INTERRUPT_STATUS_CAUSE_LOW;    \
    hal_interrupt_sr_mask_shadow &=~(1 << _shift);                      \
}                                                                       \
else {                                                                  \
    _shift = (_vector_) - CYGNUM_HAL_INTERRUPT_SYSCTL_LOW;              \
    *S_IMR &=~(1 << _shift);                                            \
}                                                                       \
HAL_RESTORE_INTERRUPTS( _intstate );                                    \
CYG_MACRO_END


#define HAL_INTERRUPT_UNMASK( _vector_ )                                \
CYG_MACRO_START                                                         \
register int _intstate;                                                 \
register int _shift;                                                    \
HAL_DISABLE_INTERRUPTS( _intstate );                                    \
if ( CYGNUM_HAL_INTERRUPT_SYSCTL_LOW > (_vector_) ) {                   \
    /* mask starts at bit 8 */                                          \
    _shift = 8 + (_vector_) - CYGNUM_HAL_INTERRUPT_STATUS_CAUSE_LOW;    \
    hal_interrupt_sr_mask_shadow |= (1 << _shift);                      \
}                                                                       \
else {                                                                  \
    _shift = (_vector_) - CYGNUM_HAL_INTERRUPT_SYSCTL_LOW;              \
    *S_IMR |= (1 << _shift);                                            \
}                                                                       \
HAL_RESTORE_INTERRUPTS( _intstate );                                    \
CYG_MACRO_END

Re: [ECOS] RM7000 interrupt handling

[Robin Farine]

Hugo Tyson <hmt@redhat.com> writes:

[...]

> There is a neat enough solution, which I have implemented in the target we
> have that does have individual mask bits in the SR.

A pretty nice one, well done!

[...]

Re: [ECOS] RM7000 interrupt handling

[Hugo Tyson]

Robin Farine <acnrf@dial.eunet.ch> writes:
> Hugo Tyson <hmt@redhat.com> writes:
> > There is a neat enough solution, which I have implemented in the target we
> > have that does have individual mask bits in the SR.
> 
> A pretty nice one, well done!

Thanks Dude, it was NickG's idea to use the shadow copy - it's the only
way.  He had to do the same for some other hardware that had no separate
disable-all bit at all, only the complete set of individual masks.  That
suffered the same inherent race condition.

	- Huge