I have used the sntp eCos. I don't use authentication, but did have a
problem a while back with the sntp code not working with ntp servers
that were configured to do NTP auth. The eCos sntp code includes the
KeyIdentifier and MessageDigest fields in it's NTP packets to the NTP
server, but it
I used the eCos SNTP code. The code I used is about 8 years old, so
maybe things have changed some. I don't know anything about NTP/v4 or
Autokey protocol.
On 8/20/2013 2:34 PM, vxWorker wrote:
Hi Jay, thanks for your response, I 'll keep that in mind. Were you
using SNTP included in eCos?
Just because eCos does not have a pipe or socketpair feature does not
mean that you cannot use an additional pair of sockets. Add another
socket (UDP on the loopback interface) to listen on in your select()
call. Add another socket (UDP) to send messages to it using sendto().
You can bind
Use
default_value { \Foobar\ }
There are many examples in the eCos repository that do this.
Jay
On 3/21/2012 1:31 PM, Grant Edwards wrote:
How do I get a quoted string as a default value for a CDL option?
If I put
default_value {Foobar}
I get this:
#define CYG_WHATEVER Foobar
Perhaps the IPV6CTL_AUTO_LINKLOCAL sysctl() (enable
CYGPKG_NET_FREEBSD_SYSCTL) might work?
Jay
On 2/16/2012 12:06 PM, Grant Edwards wrote:
What's the simplest/best way to disable IPv6 at runtime?
For IPv4 if you never set up any addresses or routes, then that's
disabled enough since it won't
Try
/* Set the socket for non-blocking mode. */
int yes = 1;
if (ioctl(fd, FIONBIO, yes) 0)
{
/* Error */
}
Jay
On 1/20/2012 6:01 AM, Grant Edwards wrote:
The eCos reference talks about how sockets behave when their marked as
non-blocking. How does one set a
Has anyone had any success in getting the I2C controller to work on the
Samsung S3C2510A, S3C4510B, or S3C4530A? It looks like the same or
similar I2C controller in each of these MCUs.
Jay
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list
of my issue, I think that CYG_HAL_TABLE_BEGIN,
CYG_HAL_TABLE_END, and CYG_HAL_TABLE_TYPE should all use the same
alignment.
Jay
On 1/25/2011 6:02 AM, Sergei Gavrikov wrote:
Hi Jay,
On Thu, 20 Jan 2011, Jay Foster wrote:
Looking at the definition of CYG_HAL_TABLE_TYPE and
CYG_HAL_TABLE_BEGIN, I
I have used the CYG_HAL_TABLE mechanism before with success, but I am
now running into an alignment problem with a new application. This is
on an ARM architecture.
I have an object defined as:
typedef struct
{
} CYG_HAL_TABLE_TYPE MY_TYPE;
I then declare the HAL table array as:
(CYGARC_P2ALIGNMENT is 2 and CYGARC_ALIGNMENT is 4). This would result
in the table label being 4 byte aligned and the elements 16 byte aligned.
The question is why has this not caused me problems before this?
Jay
On 1/20/2011 9:30 AM, Jay Foster wrote:
I have used the CYG_HAL_TABLE mechanism before
You can either use the FreeBSD libalias library and do it from user
space (works for PPP), or add back in the IP Filter bits to the FreeBSD
TCP/IP stack that were removed when it was ported to eCos. The IP Filter
method is probably more generally useful, as you can also implement
firewall
I have an ethernet driver that does implement these, but I don't
actually use it. Generally, what your driver needs to do is setup the
CAM registers and modes appropriately. For my driver, CAM entry 0 is
always the station address, and the other addresses are used for
multicast addresses.
On 7/28/2010 12:56 PM, Grant Edwards wrote:
On 2010-07-28, Grant Edwardsgrant.b.edwa...@gmail.com wrote:
On 2010-07-27, Grant Edwardsgrant.b.edwa...@gmail.com wrote:
I'm seeing what appears to me to be a socket leak in the accept()
operation provided by the new BSD network stack.
The
I don't know about the socket leak, per se, but I have had some
dealings with the original BSD network stack with regards to the
accept() call. From my memory, I remember there being two queues on
which the socket might be placed (so_comp, so_incomp). Depending on the
timing, the socket
You could try TCP/IP Illustrated, Volume 2 (and volume 1) by Gary R.
Wright and W. Richard Stevens, published by Addison Wesley. It's a bit
dated, but the basics are there. It shows the network code listings,
bit by bit, with an explanation for each line.
Jay
On 7/27/2010 3:39 PM, Grant
I have a general CVS question pertaining to importing 3rd party modules
on vendor branches. I've looked through the CVS manual, but it does not
discuss my issue.
When I import an update to a 3rd party module onto it's vendor branch,
what happens to files that are no longer in the updated
I have a CDL file with a component defined. It has flavor 'bool' and a
'default_value' of 1. I do not configure this option in any of my
templates or .ecm files, so expect to get the default value
(1=enabled). However, I end up with it disabled. The .ecc file shows
that the user_value is 1
/20/2010 5:05 PM, Jay Foster wrote:
I have a CDL file with a component defined. It has flavor 'bool' and
a 'default_value' of 1. I do not configure this option in any of my
templates or .ecm files, so expect to get the default value
(1=enabled). However, I end up with it disabled. The .ecc file
According to the man page for pthread_kill, the return value is supposed
to be 0 on success and an error number (ESRCH, EINVAL) on error.
However, the eCos implementation is returning 0 on success and -1 on
error with errno set to the error number. It looks like the eCos
pthread_kill()
shouldn't be an issue.
Cheers,
Will
-Original Message-
From: Will Lentz
Sent: Thursday, October 01, 2009 4:53 PM
To: 'Jay Foster'
Cc: ecos-discuss@ecos.sourceware.org
Subject: RE: [ECOS] 'id' rollover bug in dns.c
Thanks! That's a better solution.
Will
-Original Message-
From: Jay
packet
(DHCP Offer).
[snip]
Any hint's appreciated.
Hi Mandeep,
I call that recently Jay Foster share on the list a solution
http://sourceware.org/ml/ecos-discuss/2009-06/msg00075.html
Follow this thread. HIH.
Thanks Sergei. This is _exactly_ my problem too.
Though this patch didn't help much
You can try the following patch that someone added to my local source. It
adds a CDL option (CYGOPT_NET_INET_FORCE_DIRECTED_BROADCAST) to modify this
behavior (the default being the same behavior you have now). Sorry it isn't
in patch format, but it is straight forward. What is not shown here
I don't know about that problem, but I don know that the arm-elf-gcc 3.2.1
compiler does generate bad code sometimes. I switched to 3.4.3 and no more
bad code generation. It's been too long for me to remember the specifics.
I think it had something to do with not properly manipulating the stack
I've always just used the default for Cygwin when installing Cygwin (I
ignored the eCos request to set it to DOS mode), and have never had any
problem.
Jay
-Original Message-
From: Grant Edwards [mailto:gra...@visi.com]
Sent: Wednesday, January 07, 2009 1:58 PM
To:
I have a tarball (~96MB compressed) for the 3.4.3 arm-elf gnu tools built
for Cygwin following the instructions from the eCos web site. It includes
big endian support. gcc 3.2.1 is known to be broken for ARM anyway (why I
switched to 3.4.3 several years ago). I cannot attach it to this email
link status?
On 2008-12-17, Grant Edwards gra...@visi.com wrote:
On 2008-12-17, Jay Foster j...@systech.com wrote:
You may also be able to use the SIOCGIFSTATS socket ioctl to retrieve the
eth_stats (struct ether_drv_stats) structure. You can get the speed from
the speed member and the duplex
You may also be able to use the SIOCGIFSTATS socket ioctl to retrieve the
eth_stats (struct ether_drv_stats) structure. You can get the speed from
the speed member and the duplex from the duplex member. Not all ethernet
drivers support the SIOCGIFSTATS ioctl.
Jay
-Original Message-
I've done this by implementing my own function, which calls the
_eth_phy_state() function from the Generic PHY Package. Depending on which
drivers/packages are configured, my function might call the ethernet driver
specific function (PhyStatus() for example), or the _eth_phy_state()
function when
]
Sent: Tuesday, December 16, 2008 1:15 PM
To: ecos-disc...@sources.redhat.com
Subject: [ECOS] Re: How to get Ethernet link status?
On 2008-12-16, Jay Foster j...@systech.com wrote:
I've done this by implementing my own function, which calls the
_eth_phy_state() function from the Generic PHY
I have a situation where I need to have some header files copied from their
repository directory (package/current/include/) to the install tree
(.../install/include/). I added these files using an include_files
property in the package CDL file, but they don't get copied to the install
tree. The
, 2008 9:33 AM
To: [EMAIL PROTECTED]
Subject: [ECOS] Re: How to tell if a file is being compiled as part of
eCos?
On 2008-08-01, Sergei Gavrikov [EMAIL PROTECTED] wrote:
On Thu, Jul 31, 2008 at 04:19:26PM +, Grant Edwards wrote:
On 2008-07-31, Jay Foster [EMAIL PROTECTED] wrote:
I've
I've seen many eCos packages use __ECOS (or sometimes __ECOS__) for this
purpose. __ECOS is usually defined by the associated package CDL file in a
...CFLAGS_ADD option. You can grep for __ECOS in the sources and find
examples.
Jay
-Original Message-
From: Grant Edwards [mailto:[EMAIL
I believe that the KAME/FreeBSD stack internally hacks bytes 2 and 3
(counting the first byte as byte 0) of IPv6 link-local addresses to contain
the associated interface index. The IPv6 standard defines these bytes to be
always 0, and the FreeBSD stack automatically modifies them as necessary
A colleague implemented something like this by creating a function that
could be called from various places at random times, such as the ethernet
driver (ether_input()), serial port modem signal changes, etc. The function
would read the HAL microsecond clock value and write the lower 16-bits to
?
On 2008-04-03, Jay Foster [EMAIL PROTECTED] wrote:
A colleague implemented something like this by creating a
function that could be called from various places at random
times, such as the ethernet driver (ether_input()), serial
port modem signal changes, etc. The function would read the
HAL
I am using the CYGPKG_PPP package. I also noticed the
CYGPKG_NET_FREEBSD_PPP component/option in the FreeBSD network stack CDL
file. I searched, but could find no references to this or any
documentation. I searched the eCos mailing lists and it didn't show up
anywhere. Does this option do
Shusharin [mailto:[EMAIL PROTECTED]
Sent: Monday, February 11, 2008 1:10 AM
To: Andrew Lunn
Cc: Jay Foster; ecos-discuss@ecos.sourceware.org
Subject: Re: [ECOS] BOOTP problem
В Пнд, 11/02/2008 в 09:45 +0100, Andrew Lunn пишет:
On Mon, Feb 11, 2008 at 12:44:37PM +0600, Alexey Shusharin wrote
I don't know about eCos, but I have solved a similar issue on Linux using
the SIOCGIFCONF, SIOCGIFINDEX ioctls, and the setsockopt(s, SOL_SOCKET,
SO_BINDTODEVICE) option to bind a socket to a specific interface for the
purposes of sending broadcasts.
Jay
-Original Message-
From: Dave
I'm trying to build the host tools (ecosconfig, et al) on a new install of
Fedora 8 (x86_64). I am getting the following error when running configure:
checking build system type... Invalid configuration
`x86_64-unknown-linux-gnu': machine `x86_64-unknown' not recognized.
I tried adding
there doesn't seem to be a tclConfig.sh or tkConfig.sh
file anywhere on the installation. Yes, I did install TCL and TK (version
8.4).
Jay
-Original Message-
From: Gary Thomas [mailto:[EMAIL PROTECTED]
Sent: Friday, November 30, 2007 9:08 AM
To: Jay Foster
Cc: ecos-discuss@ecos.sourceware.org
I'm having a problem using the cdl_interface CDL configury. I have a CDL
package where I have:
requires(CYGINT_XXX == 1)
cdl_interface CYGINT_XXX {
display
}
I (currently) do not have any implementations for this interface enabled. I
would
I have been having problems getting BOOTP to work using the BSD IP stack.
After perusing the code source, I discovered that there is a conditional
compile statement (BOOTP_COMPAT) that prevents BOOTP from working. If I
define BOOTP_COMPAT, then BOOTP works.
Why is the conditional compile there,
This may also be done generically from the ethernet driver's xxx_eth_start()
function. There is a 'flags' argument passed to the start function, but
unfortunately, eCos makes no use of it. However, if CYGPKG_NET is included,
the interface flags can be accessed using
I am building eCos for an ARM9 target and am getting the following error
message from the linker:
Not enough room for program headers
I have successfully built other applications (tests) and RedBoot for this
same target with no problem.
A search on Google found the following from
arm-elf-gcc 3.4.3. arm-elf-ld (GNU ld) 2.15.
Jay
-Original Message-
From: Andrew Lunn [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 26, 2006 9:36 AM
To: Jay Foster
Cc: 'ecos-discuss@ecos.sourceware.org'
Subject: Re: [ECOS] ARM Linking Problem
On Thu, Oct 26, 2006 at 09:14:02AM
and flush the caches before I load my application. All works again.
Jay
-Original Message-
From: Andrew Lunn [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 06, 2006 3:15 PM
To: Jay Foster
Subject: Re: [ECOS] ARM HAL Problems
On Thu, Jul 06, 2006 at 02:58:00PM -0700, Jay Foster wrote:
I'm
I'm using the BSD TCP/IP stack, and when my program calls
init_all_network_interfaces(), it fails the bind() call in do_dhcp(). The
errno value is EADDRNOTAVAIL (Can't assign requested address). I tracked
this down to the following statement in in_pcbbind():
if
I'm developing a new ethernet driver for an MCU that has two ethernet
interfaces. I would like to use the generic PHY driver, but have
encountered the following problem:
The two ethernet interfaces on the MCU share common MDC and MDIO signals, so
both PHYs are on the same MII bus. The
I am puzzling over how the eCos flash drivers are supposed to work when
using 16-bit wide flash devices. I'm using an ARM architecture (ARM7TDMI,
ARM940T), and the AMD AM29LV160 flash device connected in the 16-bit wide
mode (CYGNUM_FLASH_WIDTH=16).
Looking at the flash driver code, this defines
For what it's worth, I too am using gcc 3.4.3 for ARM7TDMI. I switched from
3.2.1 because 3.2.1 had a bug that generated incorrect ARM code. I forget
the details now. Inlining also works with 3.4.3.
Jay
-Original Message-
From: Birahim Larou Fall [mailto:[EMAIL PROTECTED]
Sent:
I have a CDL package that contains a cdl_interface (call it CYGINT_X) and a
boolean cdl_option (call it CYGOPT_X). The cdl_option is only active when
the cdl_interface is implemented (active_if CYGINT_X).
It is valid to have 0, 1, 2, or more implementors of CYGINT_X.
For another cdl_option, I
I ran into a similar problem with the Samsung S3C45xx HAL. However, I fixed
it by defining my own HAL_FLASH_CACHES_OFF(), HAL_FLASH_CACHES_ON() macros
in my platform HAL, which overrides that defined in flash.h.
The problem I had was that the HAL_FLASH_CACHES_OFF() macro in flash.h were
PROTECTED]
Sent: Monday, January 23, 2006 2:07 AM
To: [EMAIL PROTECTED]
Subject: Re: [ECOS] Re: ISR not causing an DSR in some rare conditions
Jay Foster [EMAIL PROTECTED] writes:
I've re-examined this patch, and have noticed that it does not 'exactly'
result in the same operation as the original code
I am experiencing a problem with a serial driver that I'm developing. It
uses separate RX and TX ISRs and DSRs. The RX and TX ISRs just schedule the
corresponding DSR to run.
The test begins by transmitting data, which is looped back to the receiver.
It starts out with:
TX ISR - TX DSR
Attached is a patch that accomplishes this.
Jay
-Original Message-
From: Jay Foster [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 07, 2005 2:38 PM
To: ecos-discuss@ecos.sourceware.org
Subject: RE: [ECOS] AMD Flash Driver Problem with CYGNUM_FLASH_16AS8
I'm putting forward
-Original Message-
From: Jay Foster [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 06, 2005 2:11 PM
To: ecos-discuss@ecos.sourceware.org
Cc: Jay Foster
Subject: [ECOS] AMD Flash Driver Problem with CYGNUM_FLASH_16AS8
I have several targets using the AMD flash driver with the following devices
Do you have ASSERTions turned on. This could help identify a problem
earlier.
I have seen other similar kinds of problems (with assertions turned on), but
have not spent any time trying to resolve them yet. Assertions such as:
eCos panic: cyg_fp_free() will close fd
eCos panic: sbdrop
eCos
57 matches
Mail list logo
