* Serial VS Diagnostic interface @ 2009-01-13 19:58 andrew wiggin 2009-01-14 0:21 ` Chris Zimman 0 siblings, 1 reply; 13+ messages in thread From: andrew wiggin @ 2009-01-13 19:58 UTC (permalink / raw) To: ecos-devel Hi all, I am working with eCos on an AT91 platform for several month now, and I have always used the serial port as a diagnostic interface for debugging purpose. However, now I need to use it as a standard serial in order to be able to use the O_NONBLOCK flag but I couldn't find a way to use the 16x55 serial driver instead of the haldiag interface: whatever I do, only the haldiag interface is selected, and removing the haldiag seems to make it impossible to compile. I know I can use the solution consisting in replacing the GETC function with a nonblocking one, and patching whatever function may need blocking calls on it, but I can't imagine there is no way in eCos to select whether my only serial port shall be considered as a diagnostic interface or a _real_ serial port. Any clue will be welcome. Thanks, -- Andrew W. ^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: Serial VS Diagnostic interface 2009-01-13 19:58 Serial VS Diagnostic interface andrew wiggin @ 2009-01-14 0:21 ` Chris Zimman 2009-01-14 13:03 ` andrew wiggin 0 siblings, 1 reply; 13+ messages in thread From: Chris Zimman @ 2009-01-14 0:21 UTC (permalink / raw) To: andrew wiggin, ecos-devel > I am working with eCos on an AT91 platform for several month now, and > I have always used the serial port as a diagnostic interface for > debugging purpose. However, now I need to use it as a standard serial > in order to be able to use the O_NONBLOCK flag but I couldn't find a > way to use the 16x55 serial driver instead of the haldiag interface: > whatever I do, only the haldiag interface is selected, and removing > the haldiag seems to make it impossible to compile. > > I know I can use the solution consisting in replacing the GETC > function with a nonblocking one, and patching whatever function may > need blocking calls on it, but I can't imagine there is no way in eCos > to select whether my only serial port shall be considered as a > diagnostic interface or a _real_ serial port. > > Any clue will be welcome. Make sure you have the hardware serial port drivers compiled in. With that you can use "/dev/ser0" etc. instead of "/dev/haldiag" and use non-blocking interfaces. --Chris ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Serial VS Diagnostic interface 2009-01-14 0:21 ` Chris Zimman @ 2009-01-14 13:03 ` andrew wiggin 2009-01-14 13:25 ` Chris Zimman 0 siblings, 1 reply; 13+ messages in thread From: andrew wiggin @ 2009-01-14 13:03 UTC (permalink / raw) To: Chris Zimman; +Cc: ecos-devel On Wed, Jan 14, 2009 at 1:20 AM, Chris Zimman <czimman@bloomberg.com> wrote: >> I am working with eCos on an AT91 platform for several month now, and >> I have always used the serial port as a diagnostic interface for >> debugging purpose. However, now I need to use it as a standard serial >> in order to be able to use the O_NONBLOCK flag but I couldn't find a >> way to use the 16x55 serial driver instead of the haldiag interface: >> whatever I do, only the haldiag interface is selected, and removing >> the haldiag seems to make it impossible to compile. >> >> I know I can use the solution consisting in replacing the GETC >> function with a nonblocking one, and patching whatever function may >> need blocking calls on it, but I can't imagine there is no way in eCos >> to select whether my only serial port shall be considered as a >> diagnostic interface or a _real_ serial port. >> >> Any clue will be welcome. > > Make sure you have the hardware serial port drivers compiled in. With that > you can use "/dev/ser0" etc. instead of "/dev/haldiag" and use non-blocking > interfaces. > > --Chris > Actually as it just inline code. I have already checked it is correctly included. Maybe I should have been more explicit: Is there anything to ensure the HW serial driver is correctly initialized ? Where should pc_serial_lookup() be called in a normal behavior ? I would have another question then, I have noticed that with GCC 4.2.2 (which is the one I use), the DEVTAB_ENTRY may be removed if the TABLE_END is declared before adding any additional entry. Is anybody else having the same issue ? -- Andrew W. ^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: Serial VS Diagnostic interface 2009-01-14 13:03 ` andrew wiggin @ 2009-01-14 13:25 ` Chris Zimman 2009-01-14 13:30 ` damien millescamps 2009-01-14 13:45 ` Chris Zimman 0 siblings, 2 replies; 13+ messages in thread From: Chris Zimman @ 2009-01-14 13:25 UTC (permalink / raw) To: andrew wiggin; +Cc: ecos-devel > Actually as it just inline code. I have already checked it is > correctly included. Maybe I should have been more explicit: Is there > anything to ensure the HW serial driver is correctly initialized ? > Where should pc_serial_lookup() be called in a normal behavior ? If you can build the serial tests and they pass, you should be in good shape. Alternatively, if opening "/dev/ser0" succeeds, you're good to go. > I would have another question then, I have noticed that with GCC 4.2.2 > (which is the one I use), the DEVTAB_ENTRY may be removed if the > TABLE_END is declared before adding any additional entry. Is anybody > else having the same issue ? I don't use GCC 4.x having moved to EABI a while ago, so I'm afraid I can't offer any advice here. --Chris ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Serial VS Diagnostic interface 2009-01-14 13:25 ` Chris Zimman @ 2009-01-14 13:30 ` damien millescamps 2009-01-14 14:19 ` Nick Garnett 2009-01-14 13:45 ` Chris Zimman 1 sibling, 1 reply; 13+ messages in thread From: damien millescamps @ 2009-01-14 13:30 UTC (permalink / raw) To: Chris Zimman; +Cc: andrew wiggin, ecos-devel On Wed, Jan 14, 2009 at 2:24 PM, Chris Zimman <czimman@bloomberg.com> wrote: >> Actually as it just inline code. I have already checked it is >> correctly included. Maybe I should have been more explicit: Is there >> anything to ensure the HW serial driver is correctly initialized ? >> Where should pc_serial_lookup() be called in a normal behavior ? > > If you can build the serial tests and they pass, you should be in good shape. > Alternatively, if opening "/dev/ser0" succeeds, you're good to go. > opening /dev/ser0 results in an error. Now that I know it should normally work, I can start to instrument a little bit to find out why it doesn't work for me. Thanks, -- Andrew W. >> I would have another question then, I have noticed that with GCC 4.2.2 >> (which is the one I use), the DEVTAB_ENTRY may be removed if the >> TABLE_END is declared before adding any additional entry. Is anybody >> else having the same issue ? > > I don't use GCC 4.x having moved to EABI a while ago, so I'm afraid I can't > offer any advice here. > > --Chris > > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Serial VS Diagnostic interface 2009-01-14 13:30 ` damien millescamps @ 2009-01-14 14:19 ` Nick Garnett 2009-01-14 14:58 ` damien millescamps 0 siblings, 1 reply; 13+ messages in thread From: Nick Garnett @ 2009-01-14 14:19 UTC (permalink / raw) To: damien millescamps; +Cc: Chris Zimman, andrew wiggin, ecos-devel "damien millescamps" <damien.millescamps@gmail.com> writes: > On Wed, Jan 14, 2009 at 2:24 PM, Chris Zimman <czimman@bloomberg.com> wrote: > >> Actually as it just inline code. I have already checked it is > >> correctly included. Maybe I should have been more explicit: Is there > >> anything to ensure the HW serial driver is correctly initialized ? > >> Where should pc_serial_lookup() be called in a normal behavior ? > > > > If you can build the serial tests and they pass, you should be in good shape. > > Alternatively, if opening "/dev/ser0" succeeds, you're good to go. > > > > opening /dev/ser0 results in an error. Now that I know it should > normally work, I can start to instrument a little bit to find out why > it doesn't work for me. The most common problem with serial devices is not enabling CYGPKG_IO_SERIAL_DEVICES. Obviously you also have to include the CYGPKG_IO_SERIAL package too. Note that AT91 serial devices cannot be shared between diagnostics and serial drivers. So if you want to continue using diagnostics on a particular UART, you need to disable it for the drivers. -- Nick Garnett eCos Kernel Architect eCosCentric Limited http://www.eCosCentric.com The eCos experts Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571 Registered in England and Wales: Reg No: 4422071 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Serial VS Diagnostic interface 2009-01-14 14:19 ` Nick Garnett @ 2009-01-14 14:58 ` damien millescamps 2009-01-14 15:10 ` Nick Garnett 0 siblings, 1 reply; 13+ messages in thread From: damien millescamps @ 2009-01-14 14:58 UTC (permalink / raw) To: Nick Garnett; +Cc: Chris Zimman, andrew wiggin, ecos-devel On Wed, Jan 14, 2009 at 3:19 PM, Nick Garnett <nickg@ecoscentric.com> wrote: > "damien millescamps" <damien.millescamps@gmail.com> writes: > >> On Wed, Jan 14, 2009 at 2:24 PM, Chris Zimman <czimman@bloomberg.com> wrote: >> >> Actually as it just inline code. I have already checked it is >> >> correctly included. Maybe I should have been more explicit: Is there >> >> anything to ensure the HW serial driver is correctly initialized ? >> >> Where should pc_serial_lookup() be called in a normal behavior ? >> > >> > If you can build the serial tests and they pass, you should be in good shape. >> > Alternatively, if opening "/dev/ser0" succeeds, you're good to go. >> > >> >> opening /dev/ser0 results in an error. Now that I know it should >> normally work, I can start to instrument a little bit to find out why >> it doesn't work for me. > > The most common problem with serial devices is not enabling > CYGPKG_IO_SERIAL_DEVICES. Obviously you also have to include the > CYGPKG_IO_SERIAL package too. > > Note that AT91 serial devices cannot be shared between diagnostics and > serial drivers. So if you want to continue using diagnostics on a > particular UART, you need to disable it for the drivers. > I imagine you mean CYGPKG_IO_SERIAL_<platform> instead of CYGPKG_IO_SERIAL_DEVICES which doesn't exist ? When you say it is not possible to use the Diagnostic interface and the serial drivers, is it just because of the ISR declaration ? If this is the case, I already know how to handle it, or are you talking about another issue ? -- Andrew W. > > -- > Nick Garnett eCos Kernel Architect > eCosCentric Limited http://www.eCosCentric.com The eCos experts > Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571 > Registered in England and Wales: Reg No: 4422071 > > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Serial VS Diagnostic interface 2009-01-14 14:58 ` damien millescamps @ 2009-01-14 15:10 ` Nick Garnett 2009-01-16 16:20 ` andrew wiggin 0 siblings, 1 reply; 13+ messages in thread From: Nick Garnett @ 2009-01-14 15:10 UTC (permalink / raw) To: damien millescamps; +Cc: Chris Zimman, andrew wiggin, ecos-devel "damien millescamps" <damien.millescamps@gmail.com> writes: > On Wed, Jan 14, 2009 at 3:19 PM, Nick Garnett <nickg@ecoscentric.com> wrote: > > The most common problem with serial devices is not enabling > > CYGPKG_IO_SERIAL_DEVICES. Obviously you also have to include the > > CYGPKG_IO_SERIAL package too. > > > > Note that AT91 serial devices cannot be shared between diagnostics and > > serial drivers. So if you want to continue using diagnostics on a > > particular UART, you need to disable it for the drivers. > > > > I imagine you mean CYGPKG_IO_SERIAL_<platform> instead of > CYGPKG_IO_SERIAL_DEVICES which doesn't exist ? No, I really do mean CYGPKG_IO_SERIAL_DEVICES, which is an option in the CYGPKG_IO_SERIAL package. It causes the serial devices to be enabled. If you cannot see it, then that probably means that CYGPKG_IO_SERIAL is not included or enabled. > > When you say it is not possible to use the Diagnostic interface and > the serial drivers, is it just because of the ISR declaration ? If > this is the case, I already know how to handle it, or are you talking > about another issue ? It has more to do with the DMA engines. The PDC is used to overcome the UART's lack of FIFOs. Once the drivers are loaded they point the DMA engines at their own buffers, not those previously used by the diagnostic channel. As a result the diagnostic channel code will no longer work. -- Nick Garnett eCos Kernel Architect eCosCentric Limited http://www.eCosCentric.com The eCos experts Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571 Registered in England and Wales: Reg No: 4422071 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Serial VS Diagnostic interface 2009-01-14 15:10 ` Nick Garnett @ 2009-01-16 16:20 ` andrew wiggin 2009-01-16 16:23 ` Chris Zimman 0 siblings, 1 reply; 13+ messages in thread From: andrew wiggin @ 2009-01-16 16:20 UTC (permalink / raw) To: Nick Garnett; +Cc: damien millescamps, Chris Zimman, ecos-devel Thanks to all for your help. Actually, my UART (which is a synthetisable IP eventually), has a slight modification from the original 16X5X behavior. I have added a DEFINE in order to declare an extra register and do some extra checks in the Init and DSR functions. This is quite an odd situation, because the documentation of the IP is subject to non disclosure, but the fact that I modified some GPL code means I should provide my modifications. I have thought of two solutions: continuing with my old driver so that no GPL applies, or propose a patch with the modifications without documenting for which IP vendor it applies, and in which configuration... How do you guys handle this kind of situation ? -- Andrew W. On Wed, Jan 14, 2009 at 4:09 PM, Nick Garnett <nickg@ecoscentric.com> wrote: > "damien millescamps" <damien.millescamps@gmail.com> writes: > >> On Wed, Jan 14, 2009 at 3:19 PM, Nick Garnett <nickg@ecoscentric.com> wrote: >> > The most common problem with serial devices is not enabling >> > CYGPKG_IO_SERIAL_DEVICES. Obviously you also have to include the >> > CYGPKG_IO_SERIAL package too. >> > >> > Note that AT91 serial devices cannot be shared between diagnostics and >> > serial drivers. So if you want to continue using diagnostics on a >> > particular UART, you need to disable it for the drivers. >> > >> >> I imagine you mean CYGPKG_IO_SERIAL_<platform> instead of >> CYGPKG_IO_SERIAL_DEVICES which doesn't exist ? > > No, I really do mean CYGPKG_IO_SERIAL_DEVICES, which is an option in > the CYGPKG_IO_SERIAL package. It causes the serial devices to be > enabled. If you cannot see it, then that probably means that > CYGPKG_IO_SERIAL is not included or enabled. > >> >> When you say it is not possible to use the Diagnostic interface and >> the serial drivers, is it just because of the ISR declaration ? If >> this is the case, I already know how to handle it, or are you talking >> about another issue ? > > It has more to do with the DMA engines. The PDC is used to overcome > the UART's lack of FIFOs. Once the drivers are loaded they point the > DMA engines at their own buffers, not those previously used by the > diagnostic channel. As a result the diagnostic channel code will no > longer work. > > > -- > Nick Garnett eCos Kernel Architect > eCosCentric Limited http://www.eCosCentric.com The eCos experts > Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571 > Registered in England and Wales: Reg No: 4422071 > > ^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: Serial VS Diagnostic interface 2009-01-16 16:20 ` andrew wiggin @ 2009-01-16 16:23 ` Chris Zimman 2009-01-16 17:35 ` Jonathan Larmour 0 siblings, 1 reply; 13+ messages in thread From: Chris Zimman @ 2009-01-16 16:23 UTC (permalink / raw) To: andrew wiggin, ecos-devel > Actually, my UART (which is a synthetisable IP eventually), has a > slight modification from the original 16X5X behavior. I have added a > DEFINE in order to declare an extra register and do some extra checks > in the Init and DSR functions. > This is quite an odd situation, because the documentation of the IP is > subject to non disclosure, but the fact that I modified some GPL code > means I should provide my modifications. I have thought of two > solutions: continuing with my old driver so that no GPL applies, or > propose a patch with the modifications without documenting for which > IP vendor it applies, and in which configuration... If this is IP that was customized by you (eg. presumably specific to a given part), why would a patch need to go back into the mainline tree? WRT what the NDA covers in terms of the documents and how the GPL affects all of that, you'd probably better get clarification from a lawyer. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Serial VS Diagnostic interface 2009-01-16 16:23 ` Chris Zimman @ 2009-01-16 17:35 ` Jonathan Larmour 2009-01-16 19:02 ` andrew wiggin 0 siblings, 1 reply; 13+ messages in thread From: Jonathan Larmour @ 2009-01-16 17:35 UTC (permalink / raw) To: Chris Zimman; +Cc: andrew wiggin, ecos-devel Chris Zimman wrote: >> Actually, my UART (which is a synthetisable IP eventually), has a >> slight modification from the original 16X5X behavior. I have added a >> DEFINE in order to declare an extra register and do some extra checks >> in the Init and DSR functions. >> This is quite an odd situation, because the documentation of the IP is >> subject to non disclosure, but the fact that I modified some GPL code >> means I should provide my modifications. I have thought of two >> solutions: continuing with my old driver so that no GPL applies, or >> propose a patch with the modifications without documenting for which >> IP vendor it applies, and in which configuration... > > If this is IP that was customized by you (eg. presumably specific to a given > part), why would a patch need to go back into the mainline tree? I think he means the driver was customised, to adapt to the IP. Andrew: in case it's any help, the GPL clause 3(a) releases you from any obligation to make public any source code *provided* that you accompany any binary image (or product containing the binary image) with the relevant source code. This means that if you are only distributing it to people who have also already signed the NDA, then as long as you include the source code with it at the same time you should be ok (I should add a disclaimer: I am not a lawyer!). If they want to distribute it further, it's up to them to comply with the licence. I believe the potential conflict with NDAs is dealt with under GPL clause 7, essentially: "If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all. " So your own driver might be the better solution. I would doubt that having a patch but not documenting the IP vendor would be sufficient to avoid the letter of your NDA. Alternatively it may be easiest to ping whoever you have the NDA with to ask if its ok to make public code using that register. It doesn't sound to me like one particular register in a UART is something that is really the focus of the private IP they are trying to conceal by NDA. A lot of companies just habitually have NDAs for everything that they aren't actually making public themselves. Of course I Am Not A Lawyer. Jifl -- eCosCentric Limited http://www.eCosCentric.com/ The eCos experts Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571 Registered in England and Wales: Reg No 4422071. ------["Si fractum non sit, noli id reficere"]------ Opinions==mine ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Serial VS Diagnostic interface 2009-01-16 17:35 ` Jonathan Larmour @ 2009-01-16 19:02 ` andrew wiggin 0 siblings, 0 replies; 13+ messages in thread From: andrew wiggin @ 2009-01-16 19:02 UTC (permalink / raw) To: Jonathan Larmour; +Cc: Chris Zimman, ecos-devel > Andrew: in case it's any help, the GPL clause 3(a) releases you from any > obligation to make public any source code *provided* that you accompany any > binary image (or product containing the binary image) with the relevant > source code. This means that if you are only distributing it to people who > have also already signed the NDA, then as long as you include the source > code with it at the same time you should be ok (I should add a disclaimer: > I am not a lawyer!). If they want to distribute it further, it's up to them > to comply with the licence. > Thanks for the clarification. Considering the code is only distributed to people sharing the NDA, and that it is always distributed in source format with all modifications clearly mentioned, everything should be OK. -- Andrew W. > I believe the potential conflict with NDAs is dealt with under GPL clause > 7, essentially: "If you cannot distribute so as to satisfy simultaneously > your obligations under this License and any other pertinent obligations, > then as a consequence you may not distribute the Program at all. " > > So your own driver might be the better solution. I would doubt that having > a patch but not documenting the IP vendor would be sufficient to avoid the > letter of your NDA. > > Alternatively it may be easiest to ping whoever you have the NDA with to > ask if its ok to make public code using that register. It doesn't sound to > me like one particular register in a UART is something that is really the > focus of the private IP they are trying to conceal by NDA. A lot of > companies just habitually have NDAs for everything that they aren't > actually making public themselves. > > Of course I Am Not A Lawyer. > > Jifl > -- > eCosCentric Limited http://www.eCosCentric.com/ The eCos experts > Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571 > Registered in England and Wales: Reg No 4422071. > ------["Si fractum non sit, noli id reficere"]------ Opinions==mine > ^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: Serial VS Diagnostic interface 2009-01-14 13:25 ` Chris Zimman 2009-01-14 13:30 ` damien millescamps @ 2009-01-14 13:45 ` Chris Zimman 1 sibling, 0 replies; 13+ messages in thread From: Chris Zimman @ 2009-01-14 13:45 UTC (permalink / raw) To: andrew wiggin; +Cc: ecos-devel >> I would have another question then, I have noticed that with GCC 4.2.2 >> (which is the one I use), the DEVTAB_ENTRY may be removed if the >> TABLE_END is declared before adding any additional entry. Is anybody >> else having the same issue ? > I don't use GCC 4.x having moved to EABI a while ago, so I'm afraid I > can't offer any advice here. Just for the purposes of clarification: The EABI toolchain is 4.x based, but I assumed what you were talking about is the standard GNU arm-elf toolchain. The linker script is modified under EABI though, and I personally haven't seen any issues with the tables. --Chris ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2009-01-16 19:02 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-01-13 19:58 Serial VS Diagnostic interface andrew wiggin 2009-01-14 0:21 ` Chris Zimman 2009-01-14 13:03 ` andrew wiggin 2009-01-14 13:25 ` Chris Zimman 2009-01-14 13:30 ` damien millescamps 2009-01-14 14:19 ` Nick Garnett 2009-01-14 14:58 ` damien millescamps 2009-01-14 15:10 ` Nick Garnett 2009-01-16 16:20 ` andrew wiggin 2009-01-16 16:23 ` Chris Zimman 2009-01-16 17:35 ` Jonathan Larmour 2009-01-16 19:02 ` andrew wiggin 2009-01-14 13:45 ` Chris Zimman
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).