[ECOS] LPC2214 Porting issue: Garbage data on Serial Console

[ECOS] LPC2214 Porting issue: Garbage data on Serial Console

[Tom B]

Hello eCos list,

  In my effort to port eCos to a LPC2214-based board, I'm running into
some troubles with the serial port.  When I load Redboot and execute
it, I get garbage data outputted on the serial port, about 80 bytes.
The execution then gets stuck attempting to read a character from the
console - here is the backtrace at this point:

#0  hal_clock_read (pvalue=0x8101afbc)
    at /opt/ecos/ecos-cvs/packages/hal/arm/lpc2xxx/var/current/src/lpc2xxx_misc.
c:124
#1  0x81006ac0 in delay_us (usecs=0x64)
    at /opt/ecos/ecos-cvs/packages/hal/common/current/src/hal_if.c:226
#2  0x810126fc in cyg_hal_plf_serial_getc_timeout (__ch_data=0x81018cdc,
    ch=0x8101b04f "\201dù\001\201\001") at hal_if.h:639
#3  0x8100fe6c in mon_read_char_with_timeout (
    c=0x8101b04f "\201dù\001\201\001") at hal_if.h:335
#4  0x81010114 in $a ()
    at /opt/ecos/ecos-cvs/packages/redboot/current/src/io.c:386
#5  0x81010114 in $a ()
    at /opt/ecos/ecos-cvs/packages/redboot/current/src/io.c:386

The key is frame 2, as 1 and 0 are just delaying before polling the
device again for data.  If I attempt to enter characters, it is not
detected by the program.

If I build eCos as a library, and build and link a "hello world" app,
I get no serial output, but instead for some reason my call to printf
prompts a chain of events that ends up calling cyg_hal_plf_serial_getc
(which I find odd, since I'm telling it to print to the console, not
read from the console..).  Here is the stack trace when it is waiting
for a character, initially prompted by a call to printf:

(arm-gdb) bt
#0  cyg_hal_plf_serial_getc_nonblock (__ch_data=0xe0010000,
    ch=0x81027cbb "_\217")
    at /opt/ecos/ecos-cvs/packages/hal/arm/lpc2xxx/var/current/src/hal_diag.c:12
4
#1  0x81012a38 in cyg_hal_plf_serial_getc (__ch_data=0x81021298)
    at /opt/ecos/ecos-cvs/packages/hal/arm/lpc2xxx/var/current/src/hal_diag.c:13
7
#2  0x81003608 in cyg_hal_diag_mangler_gdb_flush (__ch_data=0xe0010000)
    at hal_if.h:311
#3  0x81003a08 in hal_if_diag_write_char (c=0x0) at hal_if.h:305
#4  0x81015c44 in haldiag_putc (chan=0xe0010000, c=0xbb)
    at /opt/ecos/ecos-cvs/packages/io/serial/current/src/common/haldiag.c:114
#5  0x81015200 in serial_write (handle=0xe0010000, _buf=0x81027cbb,
    len=0x81027d7c)
    at /opt/ecos/ecos-cvs/packages/io/serial/current/src/common/serial.c:331
#6  0x81012f78 in cyg_io_write (handle=0xe0010000, buf=0x81027cbb, len=0x60)
    at /opt/ecos/ecos-cvs/packages/io/common/current/src/iosys.c:178
#7  0x81015978 in tty_write (handle=0xe0010000, _buf=0x81027cbb,
    len=0x81027e00)
    at /opt/ecos/ecos-cvs/packages/io/serial/current/src/common/tty.c:190
#8  0x81012f78 in cyg_io_write (handle=0xe0010000, buf=0x81027cbb, len=0x60)
    at /opt/ecos/ecos-cvs/packages/io/common/current/src/iosys.c:178
#9  0x8101156c in Cyg_StdioStream::flush_output_unlocked (this=0x81025b14)
    at io.inl:229
#10 0x81012300 in Cyg_StdioStream::write (this=0x81025b14,
    buffer=0x8101c9eb "", buffer_length=0x0, bytes_written=0x81027f08)
    at /opt/ecos/ecos-cvs/packages/language/c/libc/stdio/current/src/common/stre
am.cxx:701
#11 0x81006534 in $a ()
    at /opt/ecos/ecos-cvs/packages/language/c/libc/stdio/current/src/output/vfnp
rintf.cxx:277
#12 0x81006534 in $a ()
    at /opt/ecos/ecos-cvs/packages/language/c/libc/stdio/current/src/output/vfnp
rintf.cxx:277
(arm-gdb)

Again, entering a character does not force the application to exit the
getc call (I am sure of this, I set a breakpoint following the getc).

I know that the serial port and interface to the computer is working
fine, as I've tested both with loopback devices and also I have code
that manually manipulates the LPC registers to interact with the
serial port, and both work fine.

Anyone have any suggestions on how I can debug this problem, or ideas
on what's causing it?

Cheers,
Tom Burns

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: LPC2214 Porting issue: Garbage data on Serial Console

[Tom B]

An update:  I fixed the output problem in Redboot and now get the
Redboot header during initialization as I should - the problem was
that I had the wrong clock input defined so the math for calculating
delays was incorrect, resulting in the wrong baud rate.
Unfortunately, Redboot still does not recognize input from the serial
application.

As well, the second stack trace is still occuring when I try to do a
printf while just linking against the target library.

Any ideas?

Thanks,
Tom

On 6/2/06, Tom B <tom.i.burns@gmail.com> wrote:
> Hello eCos list,
>
>   In my effort to port eCos to a LPC2214-based board, I'm running into
> some troubles with the serial port.  When I load Redboot and execute
> it, I get garbage data outputted on the serial port, about 80 bytes.
> The execution then gets stuck attempting to read a character from the
> console - here is the backtrace at this point:
>
> #0  hal_clock_read (pvalue=0x8101afbc)
>     at /opt/ecos/ecos-cvs/packages/hal/arm/lpc2xxx/var/current/src/lpc2xxx_misc.
> c:124
> #1  0x81006ac0 in delay_us (usecs=0x64)
>     at /opt/ecos/ecos-cvs/packages/hal/common/current/src/hal_if.c:226
> #2  0x810126fc in cyg_hal_plf_serial_getc_timeout (__ch_data=0x81018cdc,
>     ch=0x8101b04f "\201dù\001\201\001") at hal_if.h:639
> #3  0x8100fe6c in mon_read_char_with_timeout (
>     c=0x8101b04f "\201dù\001\201\001") at hal_if.h:335
> #4  0x81010114 in $a ()
>     at /opt/ecos/ecos-cvs/packages/redboot/current/src/io.c:386
> #5  0x81010114 in $a ()
>     at /opt/ecos/ecos-cvs/packages/redboot/current/src/io.c:386
>
> The key is frame 2, as 1 and 0 are just delaying before polling the
> device again for data.  If I attempt to enter characters, it is not
> detected by the program.
>
> If I build eCos as a library, and build and link a "hello world" app,
> I get no serial output, but instead for some reason my call to printf
> prompts a chain of events that ends up calling cyg_hal_plf_serial_getc
> (which I find odd, since I'm telling it to print to the console, not
> read from the console..).  Here is the stack trace when it is waiting
> for a character, initially prompted by a call to printf:
>
> (arm-gdb) bt
> #0  cyg_hal_plf_serial_getc_nonblock (__ch_data=0xe0010000,
>     ch=0x81027cbb "_\217")
>     at /opt/ecos/ecos-cvs/packages/hal/arm/lpc2xxx/var/current/src/hal_diag.c:12
> 4
> #1  0x81012a38 in cyg_hal_plf_serial_getc (__ch_data=0x81021298)
>     at /opt/ecos/ecos-cvs/packages/hal/arm/lpc2xxx/var/current/src/hal_diag.c:13
> 7
> #2  0x81003608 in cyg_hal_diag_mangler_gdb_flush (__ch_data=0xe0010000)
>     at hal_if.h:311
> #3  0x81003a08 in hal_if_diag_write_char (c=0x0) at hal_if.h:305
> #4  0x81015c44 in haldiag_putc (chan=0xe0010000, c=0xbb)
>     at /opt/ecos/ecos-cvs/packages/io/serial/current/src/common/haldiag.c:114
> #5  0x81015200 in serial_write (handle=0xe0010000, _buf=0x81027cbb,
>     len=0x81027d7c)
>     at /opt/ecos/ecos-cvs/packages/io/serial/current/src/common/serial.c:331
> #6  0x81012f78 in cyg_io_write (handle=0xe0010000, buf=0x81027cbb, len=0x60)
>     at /opt/ecos/ecos-cvs/packages/io/common/current/src/iosys.c:178
> #7  0x81015978 in tty_write (handle=0xe0010000, _buf=0x81027cbb,
>     len=0x81027e00)
>     at /opt/ecos/ecos-cvs/packages/io/serial/current/src/common/tty.c:190
> #8  0x81012f78 in cyg_io_write (handle=0xe0010000, buf=0x81027cbb, len=0x60)
>     at /opt/ecos/ecos-cvs/packages/io/common/current/src/iosys.c:178
> #9  0x8101156c in Cyg_StdioStream::flush_output_unlocked (this=0x81025b14)
>     at io.inl:229
> #10 0x81012300 in Cyg_StdioStream::write (this=0x81025b14,
>     buffer=0x8101c9eb "", buffer_length=0x0, bytes_written=0x81027f08)
>     at /opt/ecos/ecos-cvs/packages/language/c/libc/stdio/current/src/common/stre
> am.cxx:701
> #11 0x81006534 in $a ()
>     at /opt/ecos/ecos-cvs/packages/language/c/libc/stdio/current/src/output/vfnp
> rintf.cxx:277
> #12 0x81006534 in $a ()
>     at /opt/ecos/ecos-cvs/packages/language/c/libc/stdio/current/src/output/vfnp
> rintf.cxx:277
> (arm-gdb)
>
> Again, entering a character does not force the application to exit the
> getc call (I am sure of this, I set a breakpoint following the getc).
>
> I know that the serial port and interface to the computer is working
> fine, as I've tested both with loopback devices and also I have code
> that manually manipulates the LPC registers to interact with the
> serial port, and both work fine.
>
> Anyone have any suggestions on how I can debug this problem, or ideas
> on what's causing it?
>
> Cheers,
> Tom Burns
>

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Dynamic IP/DHCP/Routing the 'right way'

[Laurie Gellatly]

Hi All,
I'll be working with the PHYTEC2294 board in preparation to using the
Philips LPC2210 and LPC2102 in production.

My project will allow the user to change the various IP settings
(Address/Mask/gateway/DHCP) while the system is running. I.E. address
and mask are updated (old addresses are deleted).
Gateway changes cause the default route to be updated. DHCP can be
turned off/on.

I've found some older posts about this and tried them. Maybe I missed
something but so far I've not found a single solution that covers all my
needs. Is there such a solution or is there a 'right way' to achieve
this?

Also saw a post about using an incoming packet to learn the IP when the
device is ping'ed for instance. This could be quite useful as well.
Anyone have this in code already or can at least point me in the right
direction of what to do?

After these I'll need to do the same for NTP and DNS.

Cheers			...Laurie:{)


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Dynamic IP/DHCP/Routing the 'right way'

[Andrew Lunn]

On Tue, Jun 06, 2006 at 08:36:52PM +1000, Laurie Gellatly wrote:
> Hi All,
> I'll be working with the PHYTEC2294 board in preparation to using the
> Philips LPC2210 and LPC2102 in production.
> 
> My project will allow the user to change the various IP settings
> (Address/Mask/gateway/DHCP) while the system is running. I.E. address
> and mask are updated (old addresses are deleted).
> Gateway changes cause the default route to be updated. DHCP can be
> turned off/on.
> 
> I've found some older posts about this and tried them. Maybe I missed
> something but so far I've not found a single solution that covers all my
> needs. Is there such a solution or is there a 'right way' to achieve
> this?

You might need to write your own dhcp management thread which calls
the dhcp state machine as needed, or calls the init_net() function
with your static addressing information.

> After these I'll need to do the same for NTP and DNS.

By NTP you mean SNTP? You should be able to call
cyg_sntp_set_servers() at anytime to tell it about a change of unicast
SNTP server.

With DNS similarly cyg_dns_res_start() can be called at any time to
indicate a new server. 

         Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

RE: [ECOS] Dynamic IP/DHCP/Routing the 'right way'

[Laurie Gellatly]

Hi Andrew,
Thanks for the swift response.
SNTP - yes. Thanks for the tips there and with DNS, I'll look at those.

init_net() was not sufficient. It left the old addresses active. I've
combined StackInit and IP_SetIP, IP_SetMask to remove the old address
and mask. Still think the routing is not being updated, but before I
launched into debugging all that I wanted to ensure I wasn't
re-inventing the wheel.

Thanks			...Laurie:{)

-----Original Message-----
From: Andrew Lunn [mailto:andrew@lunn.ch] 
Sent: Tuesday, 6 June 2006 8:56 PM
To: Laurie Gellatly
Cc: ecos-discuss@ecos.sourceware.org
Subject: Re: [ECOS] Dynamic IP/DHCP/Routing the 'right way'


On Tue, Jun 06, 2006 at 08:36:52PM +1000, Laurie Gellatly wrote:
> Hi All,
> I'll be working with the PHYTEC2294 board in preparation to using the 
> Philips LPC2210 and LPC2102 in production.
> 
> My project will allow the user to change the various IP settings
> (Address/Mask/gateway/DHCP) while the system is running. I.E. address 
> and mask are updated (old addresses are deleted). Gateway changes 
> cause the default route to be updated. DHCP can be turned off/on.
> 
> I've found some older posts about this and tried them. Maybe I missed 
> something but so far I've not found a single solution that covers all 
> my needs. Is there such a solution or is there a 'right way' to 
> achieve this?

You might need to write your own dhcp management thread which calls the
dhcp state machine as needed, or calls the init_net() function with your
static addressing information.

> After these I'll need to do the same for NTP and DNS.

By NTP you mean SNTP? You should be able to call
cyg_sntp_set_servers() at anytime to tell it about a change of unicast
SNTP server.

With DNS similarly cyg_dns_res_start() can be called at any time to
indicate a new server. 

         Andrew


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] eCos meets SHTTPD (web server)

[Laurie Gellatly]

On another note,
I've been working on SHTTPD as my ARM project's web server. The built in
server unfortunately didn't have some facilities I needed and goAhead
required its logo on the front page of the final product. I have a
version running now that uses eCos to setup the threads and sockets (and
I believe should also work with IPv6) and uses SHTTPD to do the serving.
For those that don't know about SHTTPD you can see details here:
http://shttpd.sourceforge.net It has a MIT license and provides Digest
Access Authentication, SSL, GET, POST. Like the eCos server it also has
embedded calls and there appears to be facilities for a ROM file system
(though I've not looked at that). I've modified SHTTPD to check on
'Last-Modified-Since' so that static elements, like images, are not
repeatedly downloaded to the browser. 

I've extended DAA (login with encrypted passwords and user names) to
also request login again after the user has a period of inactivity. 

Tried it with IE6 and Firefox 1.5 OK.

Drop me a line if you're interested.

Cheers			...Laurie:{)


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Dynamic IP/DHCP/Routing the 'right way'

[Andrew Lunn]

On Tue, Jun 06, 2006 at 09:09:29PM +1000, Laurie Gellatly wrote:
> Hi Andrew,
> Thanks for the swift response.
> SNTP - yes. Thanks for the tips there and with DNS, I'll look at those.
> 
> init_net() was not sufficient. It left the old addresses active. I've
> combined StackInit and IP_SetIP, IP_SetMask to remove the old address
> and mask. Still think the routing is not being updated, but before I
> launched into debugging all that I wanted to ensure I wasn't
> re-inventing the wheel.

I think this is a new wheel, at least i've not seen a public available
wheel which does this.

cyg_route_reinit() might help with your routing problem.

     Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

RE: [ECOS] Dynamic IP/DHCP/Routing the 'right way'

[Joe Porthouse]

Laurie,
Did you find a solution that worked?  I'm also dealing with this same issue.
Thanks,
Joe Porthouse
Toptech Systems, Inc.
Longwood, FL 32750

-----Original Message-----
From: ecos-discuss-owner@ecos.sourceware.org
[mailto:ecos-discuss-owner@ecos.sourceware.org] On Behalf Of Andrew Lunn
Sent: Tuesday, June 06, 2006 7:19 AM
To: Laurie Gellatly
Cc: ecos-discuss@ecos.sourceware.org
Subject: Re: [ECOS] Dynamic IP/DHCP/Routing the 'right way'

On Tue, Jun 06, 2006 at 09:09:29PM +1000, Laurie Gellatly wrote:
> Hi Andrew,
> Thanks for the swift response.
> SNTP - yes. Thanks for the tips there and with DNS, I'll look at those.
> 
> init_net() was not sufficient. It left the old addresses active. I've
> combined StackInit and IP_SetIP, IP_SetMask to remove the old address
> and mask. Still think the routing is not being updated, but before I
> launched into debugging all that I wanted to ensure I wasn't
> re-inventing the wheel.

I think this is a new wheel, at least i've not seen a public available
wheel which does this.

cyg_route_reinit() might help with your routing problem.

     Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss




-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

RE: [ECOS] Dynamic IP/DHCP/Routing the 'right way'

[Laurie Gellatly]

Hi Joe,
Taking Andrew's suggestion I rolled my own. Would you like to see a copy?

			...Laurie:{)

-----Original Message-----
From: Joe Porthouse [mailto:jporthouse@toptech.com]
Sent: Saturday, 29 July 2006 7:30 AM
To: ecos-discuss@ecos.sourceware.org; 'Laurie Gellatly'
Subject: RE: [ECOS] Dynamic IP/DHCP/Routing the 'right way'


Laurie,
Did you find a solution that worked?  I'm also dealing with this same issue.
Thanks,
Joe Porthouse
Toptech Systems, Inc.
Longwood, FL 32750

-----Original Message-----
From: ecos-discuss-owner@ecos.sourceware.org
[mailto:ecos-discuss-owner@ecos.sourceware.org] On Behalf Of Andrew Lunn
Sent: Tuesday, June 06, 2006 7:19 AM
To: Laurie Gellatly
Cc: ecos-discuss@ecos.sourceware.org
Subject: Re: [ECOS] Dynamic IP/DHCP/Routing the 'right way'

On Tue, Jun 06, 2006 at 09:09:29PM +1000, Laurie Gellatly wrote:
> Hi Andrew,
> Thanks for the swift response.
> SNTP - yes. Thanks for the tips there and with DNS, I'll look at those.
>
> init_net() was not sufficient. It left the old addresses active. I've
> combined StackInit and IP_SetIP, IP_SetMask to remove the old address
> and mask. Still think the routing is not being updated, but before I
> launched into debugging all that I wanted to ensure I wasn't
> re-inventing the wheel.

I think this is a new wheel, at least i've not seen a public available
wheel which does this.

cyg_route_reinit() might help with your routing problem.

     Andrew

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss




-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

RE: [ECOS] Dynamic IP/DHCP/Routing the 'right way'

[Joe Porthouse]

Laurie,
	See a copy, definitely.  Many thanks!!! :)

	I have been digging through eCos files attempting to get an
understanding of how things are working with the network, but it's kinda
like walking through an unfamiliar house with only a flashlight to show you
the way.  I have not been able to see the entire picture yet.

	I was originally looking at the DHCP code and saw during a renewal
it was shutting down the interface just before calling net_init() again.
Still having lots to do, I would rather use a solution that has worked for
someone else.

	BTW, grepping through the eCos packages I could not find StackInit,
IP_SetIP, or IP_SetMask.  Is there another package I need to install or are
these your functions?

Thanks,
Joe Porthouse
Toptech Systems, Inc.
Longwood, FL 32750
-----Original Message-----
From: Laurie Gellatly [mailto:laurie.gellatly@netic.com] 
Sent: Friday, July 28, 2006 6:01 PM
To: jporthouse@toptech.com; ecos-discuss@ecos.sourceware.org
Subject: RE: [ECOS] Dynamic IP/DHCP/Routing the 'right way'

Hi Joe,
Taking Andrew's suggestion I rolled my own. Would you like to see a copy?

			...Laurie:{)

-----Original Message-----
From: Joe Porthouse [mailto:jporthouse@toptech.com]
Sent: Saturday, 29 July 2006 7:30 AM
To: ecos-discuss@ecos.sourceware.org; 'Laurie Gellatly'
Subject: RE: [ECOS] Dynamic IP/DHCP/Routing the 'right way'


Laurie,
Did you find a solution that worked?  I'm also dealing with this same issue.
Thanks,
Joe Porthouse
Toptech Systems, Inc.
Longwood, FL 32750

-----Original Message-----
From: ecos-discuss-owner@ecos.sourceware.org
[mailto:ecos-discuss-owner@ecos.sourceware.org] On Behalf Of Andrew Lunn
Sent: Tuesday, June 06, 2006 7:19 AM
To: Laurie Gellatly
Cc: ecos-discuss@ecos.sourceware.org
Subject: Re: [ECOS] Dynamic IP/DHCP/Routing the 'right way'

On Tue, Jun 06, 2006 at 09:09:29PM +1000, Laurie Gellatly wrote:
> Hi Andrew,
> Thanks for the swift response.
> SNTP - yes. Thanks for the tips there and with DNS, I'll look at those.
>
> init_net() was not sufficient. It left the old addresses active. I've
> combined StackInit and IP_SetIP, IP_SetMask to remove the old address
> and mask. Still think the routing is not being updated, but before I
> launched into debugging all that I wanted to ensure I wasn't
> re-inventing the wheel.

I think this is a new wheel, at least i've not seen a public available
wheel which does this.

cyg_route_reinit() might help with your routing problem.

     Andrew

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss






-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

RE: [ECOS] Dynamic IP/DHCP/Routing the 'right way'

[Laurie Gellatly]

[-- Attachment #1: Type: text/plain, Size: 3448 bytes --]

Hi Joe,
I've attached my network_support.c file.
You'll see references to MCB... (that's my master control block structure)
that holds the devices configuration like DHCP enabled or not.
MCB.ucXXX are unsigned chars holding the IPv4 address as 4 bytes.

It only assumes a single eth0 (and not eth1) though it would be easy to add
that back in.

HTH			...Laurie:{)

-----Original Message-----
From: ecos-discuss-owner@ecos.sourceware.org
[mailto:ecos-discuss-owner@ecos.sourceware.org]On Behalf Of Joe
Porthouse
Sent: Saturday, 29 July 2006 11:53 AM
To: laurie.gellatly@netic.com; ecos-discuss@ecos.sourceware.org
Subject: RE: [ECOS] Dynamic IP/DHCP/Routing the 'right way'


Laurie,
	See a copy, definitely.  Many thanks!!! :)

	I have been digging through eCos files attempting to get an
understanding of how things are working with the network, but it's kinda
like walking through an unfamiliar house with only a flashlight to show you
the way.  I have not been able to see the entire picture yet.

	I was originally looking at the DHCP code and saw during a renewal
it was shutting down the interface just before calling net_init() again.
Still having lots to do, I would rather use a solution that has worked for
someone else.

	BTW, grepping through the eCos packages I could not find StackInit,
IP_SetIP, or IP_SetMask.  Is there another package I need to install or are
these your functions?

Thanks,
Joe Porthouse
Toptech Systems, Inc.
Longwood, FL 32750
-----Original Message-----
From: Laurie Gellatly [mailto:laurie.gellatly@netic.com]
Sent: Friday, July 28, 2006 6:01 PM
To: jporthouse@toptech.com; ecos-discuss@ecos.sourceware.org
Subject: RE: [ECOS] Dynamic IP/DHCP/Routing the 'right way'

Hi Joe,
Taking Andrew's suggestion I rolled my own. Would you like to see a copy?

			...Laurie:{)

-----Original Message-----
From: Joe Porthouse [mailto:jporthouse@toptech.com]
Sent: Saturday, 29 July 2006 7:30 AM
To: ecos-discuss@ecos.sourceware.org; 'Laurie Gellatly'
Subject: RE: [ECOS] Dynamic IP/DHCP/Routing the 'right way'


Laurie,
Did you find a solution that worked?  I'm also dealing with this same issue.
Thanks,
Joe Porthouse
Toptech Systems, Inc.
Longwood, FL 32750

-----Original Message-----
From: ecos-discuss-owner@ecos.sourceware.org
[mailto:ecos-discuss-owner@ecos.sourceware.org] On Behalf Of Andrew Lunn
Sent: Tuesday, June 06, 2006 7:19 AM
To: Laurie Gellatly
Cc: ecos-discuss@ecos.sourceware.org
Subject: Re: [ECOS] Dynamic IP/DHCP/Routing the 'right way'

On Tue, Jun 06, 2006 at 09:09:29PM +1000, Laurie Gellatly wrote:
> Hi Andrew,
> Thanks for the swift response.
> SNTP - yes. Thanks for the tips there and with DNS, I'll look at those.
>
> init_net() was not sufficient. It left the old addresses active. I've
> combined StackInit and IP_SetIP, IP_SetMask to remove the old address
> and mask. Still think the routing is not being updated, but before I
> launched into debugging all that I wanted to ensure I wasn't
> re-inventing the wheel.

I think this is a new wheel, at least i've not seen a public available
wheel which does this.

cyg_route_reinit() might help with your routing problem.

     Andrew

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss






--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[-- Attachment #2: network_support.c --]
[-- Type: application/octet-stream, Size: 10948 bytes --]

//==========================================================================
//
// Adapted from    network_support.c
//
//      Misc network support functions
//  $Id: network_support.c,v 1.7 2006/07/18 04:58:44 gellatly Exp $
//==========================================================================
// BOOTP support

#include <pkgconf/net.h>
#undef _KERNEL
#include <sys/param.h>
#include <sys/socket.h>
#include <sys/ioctl.h>
#include <sys/errno.h>

#include <net/if.h>
#include <netinet/in.h>
#include <netinet/ip.h>
#include <netinet/ip_icmp.h>
#include <net/route.h>

#include <cyg/infra/diag.h>
#include <cyg/kernel/kapi.h>

#include <stdio.h>    // for 'sprintf()'

#include <bootp.h>
#include <network.h>
#include <arpa/inet.h>

#include <dhcp.h>

#include <pkgconf/ns_dns.h>
#include "mydev.h"

#define CYGHWR_NET_DRIVER_ETH0_BOOTP_SHOW 1
struct bootp eth0_bootp_data;
cyg_bool_t   eth0_up = false;
const char  *eth0_name = "eth0";

#define _string(s) #s
#define string(s) _string(s)

#ifndef CYGPKG_LIBC_STDIO
#define perror(s) diag_printf(#s ": %s\n", strerror(errno))
#endif

#ifdef CYGPKG_NET_NLOOP
#if 0 < CYGPKG_NET_NLOOP
//  
//   Initialize loopback interface  ----------   Added by sorin@netappi.com 
//
cyg_bool_t init_loopback_interface(int lo)
{
    struct sockaddr_in *addrp;
    struct ifreq ifr;
    int s;
    int one = 1;
    struct ecos_rtentry route;
    struct in_addr netmask, gateway;

    s = socket(AF_INET, SOCK_DGRAM, 0); 
    if (s < 0) {
        perror("socket");
        return false;
    }
    if (setsockopt(s, SOL_SOCKET, SO_BROADCAST, &one, sizeof(one))) {
        perror("setsockopt");
	close(s);
        return false;
    }

    addrp = (struct sockaddr_in *) &ifr.ifr_addr;
    memset(addrp, 0, sizeof(*addrp));
    addrp->sin_family = AF_INET;
    addrp->sin_len = sizeof(*addrp);
    addrp->sin_port = 0;
    // Make an address 127.0.<lo>.1 to manage multiple loopback ifs.
    // (There is normally only 1, so it's the standard 127.0.0.1)
    addrp->sin_addr.s_addr = htonl((0x100 * lo) + INADDR_LOOPBACK) ; 

#if CYGPKG_NET_NLOOP > 1
    // Init the one we were told to
    sprintf(ifr.ifr_name, "lo%d", lo);
#else
    strcpy(ifr.ifr_name, "lo0");
#endif    

    if (ioctl(s, SIOCSIFADDR, &ifr)) {
        perror("SIOCIFADDR");
        close(s);
        return false;
    }
    
#if 1 < CYGPKG_NET_NLOOP
    // We cheat to make different nets for multiple loopback devs
    addrp->sin_addr.s_addr = netmask.s_addr = htonl(IN_CLASSC_NET);
#else
    // 
    addrp->sin_addr.s_addr = netmask.s_addr = htonl(IN_CLASSA_NET);
#endif
    if (ioctl(s, SIOCSIFNETMASK, &ifr)) {
        perror("SIOCSIFNETMASK");
        return false;
    }
    ifr.ifr_flags = IFF_UP | IFF_BROADCAST | IFF_RUNNING;
    if (ioctl(s, SIOCSIFFLAGS, &ifr)) {
        perror("SIOCSIFFLAGS");
        close(s);
        return false;
    }

    gateway.s_addr = htonl(INADDR_LOOPBACK);  
    memset(&route, 0, sizeof(route));
    addrp->sin_family = AF_INET;
    addrp->sin_len = sizeof(*addrp);
    addrp->sin_port = 0;
    addrp->sin_addr.s_addr = htonl((0x100 * lo) + INADDR_LOOPBACK) & netmask.s_addr;
    memcpy(&route.rt_dst, addrp, sizeof(*addrp));
    addrp->sin_addr = netmask;
    memcpy(&route.rt_genmask, addrp, sizeof(*addrp));
    addrp->sin_addr = gateway;
    memcpy(&route.rt_gateway, addrp, sizeof(*addrp));
    
    route.rt_dev = ifr.ifr_name;
    route.rt_flags = RTF_UP|RTF_GATEWAY;
    route.rt_metric = 0;

    if (ioctl(s, SIOCADDRT, &route)) {
        diag_printf("Route - dst: %s", inet_ntoa(((struct sockaddr_in *)&route.rt_dst)->sin_addr));
        diag_printf(", mask: %s", inet_ntoa(((struct sockaddr_in *)&route.rt_genmask)->sin_addr));
        diag_printf(", gateway: %s\n", inet_ntoa(((struct sockaddr_in *)&route.rt_gateway)->sin_addr));
        if (errno != EEXIST) {
            perror("SIOCADDRT 3");
            close(s);
            return false;
        }
    }
    close(s);
    return true;
}
#endif
#endif


//
// Internal function which builds up a fake BOOTP database for
// an interface.
//

static unsigned char * add_tag(unsigned char *vp,
        unsigned char tag,
        void *val,
        int len) {
    int i;
    unsigned char *xp = (unsigned char *)val;
    *vp++ = tag;
    *vp++ = len;
    for (i = 0;  i < len;  i++) {
        *vp++ = *xp++;
    }
    return vp;
}

static void build_bootp_struct(struct bootp *bp,
                   const char * if_name,
                   unsigned char addrs_ip[],
                   unsigned char addrs_netmask[],
                   unsigned char addrs_gateway[],
                   unsigned char addrs_DNSsv1[],
                   unsigned char addrs_DNSsv2[],
                   unsigned char addrs_NTPsv1[],
                   unsigned char addrs_NTPsv2[]){
    int i, s;
    in_addr_t addr[2];
    unsigned char *vp,ucAddrBuf[4];
    unsigned char cookie[] = VM_RFC1048;
    struct ifreq ifr;

    bzero(bp, sizeof(struct bootp));
    bp->bp_op = BOOTREPLY;
    bp->bp_htype = HTYPE_ETHERNET;
    bp->bp_hlen = 6;

    // Query the hardware address
    for (i = 0;  i < bp->bp_hlen;  i++) {
        bp->bp_chaddr[i] = 0xFF;  // Unknown
    }
    s = socket(AF_INET, SOCK_DGRAM, 0);
    if (s >= 0) {
        strcpy(ifr.ifr_name, if_name);
        if (ioctl(s, SIOCGIFHWADDR, &ifr) >= 0) {
            bcopy(ifr.ifr_hwaddr.sa_data, bp->bp_chaddr, bp->bp_hlen);
        }
        close(s);
    }

    // Fill in the provided IP addresses
    memcpy(&bp->bp_ciaddr.s_addr,addrs_ip,4);
    memcpy(&bp->bp_yiaddr.s_addr,addrs_ip,4);
    memcpy(&bp->bp_siaddr.s_addr,addrs_DNSsv1,4);
    memcpy(&bp->bp_giaddr.s_addr,addrs_gateway,4);
    for(i=0;i<4;++i) ucAddrBuf[i]=addrs_ip[i] | (0xFF ^ addrs_netmask[i]); //Make  the broadcast addr
    vp = &bp->bp_vend[0];
    bcopy(&cookie, vp, sizeof(cookie));
    vp += sizeof(cookie);
    vp = add_tag(vp, TAG_SUBNET_MASK, addrs_netmask, sizeof(in_addr_t));
    vp = add_tag(vp, TAG_IP_BROADCAST, ucAddrBuf, sizeof(in_addr_t));
    vp = add_tag(vp, TAG_GATEWAY, addrs_gateway, sizeof(in_addr_t));
    i=0;
    if(*(long*)addrs_DNSsv1) memcpy(&addr[i++],addrs_DNSsv1, sizeof(in_addr_t));
    if(*(long*)addrs_DNSsv2) memcpy(&addr[i++],addrs_DNSsv2, sizeof(in_addr_t));
    if(i) vp = add_tag(vp, TAG_DOMAIN_SERVER, addr, (i==2)? sizeof(in_addr_t)+sizeof(in_addr_t):sizeof(in_addr_t));
    i=0;
    if(*(long*)addrs_NTPsv1) memcpy(&addr[i++],addrs_NTPsv1, sizeof(in_addr_t));
    if(*(long*)addrs_NTPsv2) memcpy(&addr[i++],addrs_NTPsv2, sizeof(in_addr_t));
    if(i) vp = add_tag(vp, TAG_NTP_SERVER, addr, (i==2)? sizeof(in_addr_t)+sizeof(in_addr_t):sizeof(in_addr_t));
    *vp = TAG_END;
}

void del_eth0( void ) {
  int s;
  struct ifreq ifr;
  
  s = socket(PF_INET, SOCK_DGRAM, 0);
  
  if (s < 0){
      diag_printf("socket: %d\n",s);
      return;
  }
  memset(&ifr,0,sizeof( struct ifreq ) );

  strcpy(ifr.ifr_name, "eth0");

   if( ioctl( s, SIOCGIFADDR, &ifr ) == -1 ){
      diag_printf("Impossible to obtain an IP address of '%s' because '%s'",ifr.ifr_name,strerror(errno));
   } else {
      if( ioctl( s, SIOCDIFADDR, &ifr ) != 0 ){
         diag_printf("Impossible to remove IP address '%s' because '%s'",ifr.ifr_name,strerror(errno));
      }
   }
  diag_printf("del_eth0 complete.\n");
  close(s);
}

//
// Initialize network interface[s] using BOOTP/DHCP
//
void init_all_network_interfaces(void) {
    static volatile int in_init_all_network_interfaces = 0;
#ifdef CYGOPT_NET_IPV6_ROUTING_THREAD
    int rs_wait = 40;
#endif

    cyg_scheduler_lock();  // Make this call idempotent
    while ( in_init_all_network_interfaces ) {
        // Another thread is doing this...
        cyg_scheduler_unlock();
        cyg_thread_delay( 10 );
        cyg_scheduler_lock();
    }
    in_init_all_network_interfaces = 1;
    cyg_scheduler_unlock();
    if(eth0_up && ((MCB.icIPUseDHCP == 3) || ! MCB.icIPUseDHCP)){ // DHCP is coming up or not running
       del_eth0();      // Delete the old static address first
    }
    // Deal with DHCP start/stop first then static addressing
    if(MCB.icIPUseDHCP == 3){          // Change in state of DHCP to UP
       // Perform a complete initialization, using BOOTP/DHCP
       eth0_up = true;
       eth0_dhcpstate = 0; // Says that initialization is external to dhcp
       if (!do_dhcp(eth0_name, &eth0_bootp_data, &eth0_dhcpstate, &eth0_lease)){
          diag_printf("BOOTP/DHCP failed on eth0\n");
          eth0_up = false;
       }
    }else if(MCB.icIPUseDHCP == 2){    // Change in state of DHCP to down
       if ( eth0_up )  {
          // eth0_dhcpstate = 0; // Says that initialization is external to dhcp
          do_dhcp_down_net(eth0_name, &eth0_bootp_data, &eth0_dhcpstate, &eth0_lease);
       }
       eth0_up = true;
    }
    if(!(MCB.icIPUseDHCP & 1)){ // DHCP is down so set static address
       //Build the bootp data so gateway & mask tags are set correctly
       build_bootp_struct(&eth0_bootp_data,
          eth0_name,
          MCB.ucSNMPIPV4Addr,
          MCB.ucSNMPIPV4Mask,
          MCB.ucSNMPIPV4Gate,
          MCB.ucIPV4DNSServ1Addr,
          MCB.ucIPV4DNSServ2Addr,
          MCB.ucIPV4NTPServ1Addr,
          MCB.ucIPV4NTPServ2Addr);
       eth0_up = true;
    }
#ifdef CYGHWR_NET_DRIVER_ETH0_BOOTP_SHOW
    //Show what HDCP or static addresses have been setup
    show_bootp(eth0_name, &eth0_bootp_data);
#endif
    if (eth0_up) {
        if (!init_net(eth0_name, &eth0_bootp_data)) {
            diag_printf("Network initialization failed for eth0\n");
            eth0_up = false;
        }
#ifdef CYGHWR_NET_DRIVER_ETH0_IPV6_PREFIX
        if (!init_net_IPv6(eth0_name, &eth0_bootp_data, 
                           string(CYGHWR_NET_DRIVER_ETH0_IPV6_PREFIX))) {
            diag_printf("Static IPv6 network initialization failed for eth0\n");
            eth0_up = false;  // ???
        }
#endif
    }

    if(MCB.icIPUseDHCP == 3) dhcp_start_dhcp_mgt_thread();

#ifdef CYGOPT_NET_IPV6_ROUTING_THREAD
    ipv6_start_routing_thread();

    // Wait for router solicit process to happen.
    while (rs_wait-- && !cyg_net_get_ipv6_advrouter(NULL)) {
      cyg_thread_delay(10);
    }
    if (rs_wait == 0 ) {
      diag_printf("No router solicit received\n");
    } else {
      // Give Duplicate Address Detection time to work
      cyg_thread_delay(200);
    }
#endif
#ifdef CYGDAT_NS_DNS_DOMAINNAME_NAME
    {
      const char buf[] = "mycompany.com";
      int len = strlen(buf);
      
      setdomainname(buf,len);
    }
#endif
    // Open the monitor to other threads.
    in_init_all_network_interfaces = 0;
}

// EOF network_support.c


[-- Attachment #3: Type: text/plain, Size: 148 bytes --]

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss