* [ECOS] i386 TARGET network programming @ 2001-07-30 7:47 Trenton D. Adams 2001-07-30 11:59 ` Jonathan Larmour 0 siblings, 1 reply; 29+ messages in thread From: Trenton D. Adams @ 2001-07-30 7:47 UTC (permalink / raw) To: 'eCos mailing list' 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [ECOS] i386 TARGET network programming 2001-07-30 7:47 [ECOS] i386 TARGET network programming Trenton D. Adams @ 2001-07-30 11:59 ` Jonathan Larmour 2001-07-30 12:14 ` Trenton D. Adams 0 siblings, 1 reply; 29+ messages in thread From: Jonathan Larmour @ 2001-07-30 11:59 UTC (permalink / raw) To: Trenton D. Adams; +Cc: 'eCos mailing list' "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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* RE: [ECOS] i386 TARGET network programming 2001-07-30 11:59 ` Jonathan Larmour @ 2001-07-30 12:14 ` Trenton D. Adams 2001-07-30 12:20 ` Jonathan Larmour 2001-07-30 13:22 ` Fabrice Gautier 0 siblings, 2 replies; 29+ messages in thread From: Trenton D. Adams @ 2001-07-30 12:14 UTC (permalink / raw) To: 'Jonathan Larmour'; +Cc: 'eCos mailing list' > > "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. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [ECOS] i386 TARGET network programming 2001-07-30 12:14 ` Trenton D. Adams @ 2001-07-30 12:20 ` Jonathan Larmour 2001-07-30 12:34 ` Trenton D. Adams 2001-07-30 16:47 ` [ECOS] i386 TARGET network programming Fabrice Gautier 2001-07-30 13:22 ` Fabrice Gautier 1 sibling, 2 replies; 29+ messages in thread From: Jonathan Larmour @ 2001-07-30 12:20 UTC (permalink / raw) To: Trenton D. Adams; +Cc: 'eCos mailing list' "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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* RE: [ECOS] i386 TARGET network programming 2001-07-30 12:20 ` Jonathan Larmour @ 2001-07-30 12:34 ` Trenton D. Adams 2001-07-30 12:42 ` Jonathan Larmour 2001-07-30 16:47 ` [ECOS] i386 TARGET network programming Fabrice Gautier 1 sibling, 1 reply; 29+ messages in thread From: Trenton D. Adams @ 2001-07-30 12:34 UTC (permalink / raw) To: 'Jonathan Larmour'; +Cc: 'eCos mailing list' > > "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? ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [ECOS] i386 TARGET network programming 2001-07-30 12:34 ` Trenton D. Adams @ 2001-07-30 12:42 ` Jonathan Larmour 2001-07-30 12:46 ` Trenton D. Adams 0 siblings, 1 reply; 29+ messages in thread From: Jonathan Larmour @ 2001-07-30 12:42 UTC (permalink / raw) To: Trenton D. Adams; +Cc: 'eCos mailing list' "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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* RE: [ECOS] i386 TARGET network programming 2001-07-30 12:42 ` Jonathan Larmour @ 2001-07-30 12:46 ` Trenton D. Adams 2001-07-30 12:57 ` Jonathan Larmour 0 siblings, 1 reply; 29+ messages in thread From: Trenton D. Adams @ 2001-07-30 12:46 UTC (permalink / raw) To: 'Jonathan Larmour'; +Cc: 'eCos mailing list' > > > 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? ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [ECOS] i386 TARGET network programming 2001-07-30 12:46 ` Trenton D. Adams @ 2001-07-30 12:57 ` Jonathan Larmour 2001-07-30 13:01 ` Trenton D. Adams 2001-07-30 13:44 ` Trenton D. Adams 0 siblings, 2 replies; 29+ messages in thread From: Jonathan Larmour @ 2001-07-30 12:57 UTC (permalink / raw) To: Trenton D. Adams; +Cc: 'eCos mailing list' "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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* RE: [ECOS] i386 TARGET network programming 2001-07-30 12:57 ` Jonathan Larmour @ 2001-07-30 13:01 ` Trenton D. Adams 2001-07-30 13:44 ` Trenton D. Adams 1 sibling, 0 replies; 29+ messages in thread From: Trenton D. Adams @ 2001-07-30 13:01 UTC (permalink / raw) To: 'Jonathan Larmour'; +Cc: 'eCos mailing list' > > "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. ^ permalink raw reply [flat|nested] 29+ messages in thread
* RE: [ECOS] i386 TARGET network programming 2001-07-30 12:57 ` Jonathan Larmour 2001-07-30 13:01 ` Trenton D. Adams @ 2001-07-30 13:44 ` Trenton D. Adams 2001-07-30 13:46 ` Jonathan Larmour 1 sibling, 1 reply; 29+ messages in thread From: Trenton D. Adams @ 2001-07-30 13:44 UTC (permalink / raw) To: 'Jonathan Larmour'; +Cc: 'eCos mailing list' > > 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! :) ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [ECOS] i386 TARGET network programming 2001-07-30 13:44 ` Trenton D. Adams @ 2001-07-30 13:46 ` Jonathan Larmour 2001-07-30 16:39 ` [ECOS] RM7000 interrupt handling Chris Morrow 0 siblings, 1 reply; 29+ messages in thread From: Jonathan Larmour @ 2001-07-30 13:46 UTC (permalink / raw) To: Trenton D. Adams; +Cc: 'eCos mailing list' "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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* [ECOS] RM7000 interrupt handling 2001-07-30 13:46 ` Jonathan Larmour @ 2001-07-30 16:39 ` Chris Morrow 2001-07-31 5:53 ` Hugo Tyson 0 siblings, 1 reply; 29+ messages in thread From: Chris Morrow @ 2001-07-30 16:39 UTC (permalink / raw) To: 'eCos mailing list' 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [ECOS] RM7000 interrupt handling 2001-07-30 16:39 ` [ECOS] RM7000 interrupt handling Chris Morrow @ 2001-07-31 5:53 ` Hugo Tyson 2001-07-31 6:13 ` Mark Salter 0 siblings, 1 reply; 29+ messages in thread From: Hugo Tyson @ 2001-07-31 5:53 UTC (permalink / raw) To: ecos-discuss 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [ECOS] RM7000 interrupt handling 2001-07-31 5:53 ` Hugo Tyson @ 2001-07-31 6:13 ` Mark Salter 2001-07-31 7:17 ` Robin Farine 0 siblings, 1 reply; 29+ messages in thread From: Mark Salter @ 2001-07-31 6:13 UTC (permalink / raw) To: hmt; +Cc: ecos-discuss >>>>> 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [ECOS] RM7000 interrupt handling 2001-07-31 6:13 ` Mark Salter @ 2001-07-31 7:17 ` Robin Farine 2001-07-31 9:43 ` Hugo Tyson 2001-08-02 6:32 ` Hugo Tyson 0 siblings, 2 replies; 29+ messages in thread From: Robin Farine @ 2001-07-31 7:17 UTC (permalink / raw) To: Mark Salter; +Cc: hmt, ecos-discuss 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [ECOS] RM7000 interrupt handling 2001-07-31 7:17 ` Robin Farine @ 2001-07-31 9:43 ` Hugo Tyson 2001-07-31 9:59 ` Robin Farine 2001-07-31 10:28 ` Chris Morrow 2001-08-02 6:32 ` Hugo Tyson 1 sibling, 2 replies; 29+ messages in thread From: Hugo Tyson @ 2001-07-31 9:43 UTC (permalink / raw) To: acnrf; +Cc: msalter, hmt, ecos-discuss > 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [ECOS] RM7000 interrupt handling 2001-07-31 9:43 ` Hugo Tyson @ 2001-07-31 9:59 ` Robin Farine 2001-07-31 10:28 ` Chris Morrow 1 sibling, 0 replies; 29+ messages in thread From: Robin Farine @ 2001-07-31 9:59 UTC (permalink / raw) To: Hugo Tyson; +Cc: acnrf, msalter, ecos-discuss 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [ECOS] RM7000 interrupt handling 2001-07-31 9:43 ` Hugo Tyson 2001-07-31 9:59 ` Robin Farine @ 2001-07-31 10:28 ` Chris Morrow 2001-07-31 11:08 ` Hugo Tyson 1 sibling, 1 reply; 29+ messages in thread From: Chris Morrow @ 2001-07-31 10:28 UTC (permalink / raw) To: egcs; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [ECOS] RM7000 interrupt handling 2001-07-31 10:28 ` Chris Morrow @ 2001-07-31 11:08 ` Hugo Tyson 0 siblings, 0 replies; 29+ messages in thread From: Hugo Tyson @ 2001-07-31 11:08 UTC (permalink / raw) To: ecos-discuss 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [ECOS] RM7000 interrupt handling 2001-07-31 7:17 ` Robin Farine 2001-07-31 9:43 ` Hugo Tyson @ 2001-08-02 6:32 ` Hugo Tyson 2001-08-02 7:47 ` Robin Farine 1 sibling, 1 reply; 29+ messages in thread From: Hugo Tyson @ 2001-08-02 6:32 UTC (permalink / raw) To: ecos-discuss 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [ECOS] RM7000 interrupt handling 2001-08-02 6:32 ` Hugo Tyson @ 2001-08-02 7:47 ` Robin Farine 2001-08-02 8:08 ` Hugo Tyson 0 siblings, 1 reply; 29+ messages in thread From: Robin Farine @ 2001-08-02 7:47 UTC (permalink / raw) To: Hugo Tyson; +Cc: ecos-discuss 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! [...] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [ECOS] RM7000 interrupt handling 2001-08-02 7:47 ` Robin Farine @ 2001-08-02 8:08 ` Hugo Tyson 0 siblings, 0 replies; 29+ messages in thread From: Hugo Tyson @ 2001-08-02 8:08 UTC (permalink / raw) To: ecos-discuss 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [ECOS] i386 TARGET network programming 2001-07-30 12:20 ` Jonathan Larmour 2001-07-30 12:34 ` Trenton D. Adams @ 2001-07-30 16:47 ` Fabrice Gautier 2001-07-31 14:33 ` Jonathan Larmour 1 sibling, 1 reply; 29+ messages in thread From: Fabrice Gautier @ 2001-07-30 16:47 UTC (permalink / raw) To: Jonathan Larmour; +Cc: 'eCos mailing list' 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> ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [ECOS] i386 TARGET network programming 2001-07-30 16:47 ` [ECOS] i386 TARGET network programming Fabrice Gautier @ 2001-07-31 14:33 ` Jonathan Larmour 2001-07-31 14:36 ` Jonathan Larmour 0 siblings, 1 reply; 29+ messages in thread From: Jonathan Larmour @ 2001-07-31 14:33 UTC (permalink / raw) To: Fabrice Gautier; +Cc: 'eCos mailing list' 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [ECOS] i386 TARGET network programming 2001-07-31 14:33 ` Jonathan Larmour @ 2001-07-31 14:36 ` Jonathan Larmour 2001-07-31 14:44 ` Jonathan Larmour 0 siblings, 1 reply; 29+ messages in thread From: Jonathan Larmour @ 2001-07-31 14:36 UTC (permalink / raw) To: Fabrice Gautier, 'eCos mailing list' 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [ECOS] i386 TARGET network programming 2001-07-31 14:36 ` Jonathan Larmour @ 2001-07-31 14:44 ` Jonathan Larmour 2001-07-31 16:12 ` Fabrice Gautier 0 siblings, 1 reply; 29+ messages in thread From: Jonathan Larmour @ 2001-07-31 14:44 UTC (permalink / raw) To: Fabrice Gautier, 'eCos mailing list' 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [ECOS] i386 TARGET network programming 2001-07-31 14:44 ` Jonathan Larmour @ 2001-07-31 16:12 ` Fabrice Gautier 2001-07-31 17:49 ` Jonathan Larmour 0 siblings, 1 reply; 29+ messages in thread From: Fabrice Gautier @ 2001-07-31 16:12 UTC (permalink / raw) To: Jonathan Larmour; +Cc: eCos discussion 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> ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [ECOS] i386 TARGET network programming 2001-07-31 16:12 ` Fabrice Gautier @ 2001-07-31 17:49 ` Jonathan Larmour 0 siblings, 0 replies; 29+ messages in thread From: Jonathan Larmour @ 2001-07-31 17:49 UTC (permalink / raw) To: Fabrice Gautier; +Cc: eCos discussion 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [ECOS] i386 TARGET network programming 2001-07-30 12:14 ` Trenton D. Adams 2001-07-30 12:20 ` Jonathan Larmour @ 2001-07-30 13:22 ` Fabrice Gautier 1 sibling, 0 replies; 29+ messages in thread From: Fabrice Gautier @ 2001-07-30 13:22 UTC (permalink / raw) To: Trenton D. Adams; +Cc: 'eCos mailing list' 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> ^ permalink raw reply [flat|nested] 29+ messages in thread
end of thread, other threads:[~2001-08-02 8:08 UTC | newest] Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-07-30 7:47 [ECOS] i386 TARGET network programming Trenton D. Adams 2001-07-30 11:59 ` Jonathan Larmour 2001-07-30 12:14 ` Trenton D. Adams 2001-07-30 12:20 ` Jonathan Larmour 2001-07-30 12:34 ` Trenton D. Adams 2001-07-30 12:42 ` Jonathan Larmour 2001-07-30 12:46 ` Trenton D. Adams 2001-07-30 12:57 ` Jonathan Larmour 2001-07-30 13:01 ` Trenton D. Adams 2001-07-30 13:44 ` Trenton D. Adams 2001-07-30 13:46 ` Jonathan Larmour 2001-07-30 16:39 ` [ECOS] RM7000 interrupt handling Chris Morrow 2001-07-31 5:53 ` Hugo Tyson 2001-07-31 6:13 ` Mark Salter 2001-07-31 7:17 ` Robin Farine 2001-07-31 9:43 ` Hugo Tyson 2001-07-31 9:59 ` Robin Farine 2001-07-31 10:28 ` Chris Morrow 2001-07-31 11:08 ` Hugo Tyson 2001-08-02 6:32 ` Hugo Tyson 2001-08-02 7:47 ` Robin Farine 2001-08-02 8:08 ` Hugo Tyson 2001-07-30 16:47 ` [ECOS] i386 TARGET network programming Fabrice Gautier 2001-07-31 14:33 ` Jonathan Larmour 2001-07-31 14:36 ` Jonathan Larmour 2001-07-31 14:44 ` Jonathan Larmour 2001-07-31 16:12 ` Fabrice Gautier 2001-07-31 17:49 ` Jonathan Larmour 2001-07-30 13:22 ` Fabrice Gautier
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).