uIP/lwIP for Amiga OS

[hardlink]

Trev wrote:
compiled with Cygwin-hosted vbcc
Trev

What did your Makefile for vbcc look like?

[Trev]

I'm using a batch file and a custom vc.config file at the moment. The next source release will include gcc and vbcc makefles and a sample vc.config file for the vbcc vc front end. Really, it should compile with the default vbcc target packages. That shouldn't be difficult to do, assuming vbcc is installed on the host system per the vbcc documentation.

I'm no longer using gcc as there's no current support for the m68k-amigaos port. Everyone (including me) bases their packages on years old Geek Gadgets patches, and the results for building cross-compilers tend to vary. It's too bad Hyperion isn't keeping the OS3 compiler stuff up to date as they continue work on OS4. I don't have the compiler kung fu to do it myself.

Trev

[Trev]

@hardlink

Here's a Makefile that works for vbcc:

Code: [Select]


.PHONY: all clean
all: uip

CC     = vc
APPS   = dhcpc webserver
CFLAGS = -I../uip -I. -lamiga

-include ../uip/Makefile.include

uip: $(addprefix $(OBJECTDIR)/, main.o sana2dev.o clock-arch.o $(APP_SOURCES:.c=.o) $(UIP_SOURCES:.c=.o))
$(CC) $(CFLAGS) $^ -o $@

clean:
rm -fr *.o *~ *core uip $(OBJECTDIR) *.a


The default target is determined by your vc.config file. I'll expand the makefile later to allow target selection when building using the default vc config file names, e.g. aos68k. The config files need to be modified appropriately for your host (environment variables, OS include paths, etc.).

You'll also need to modify Makefile.dhcp in uip-1.0/apps/dhcpc to kill the vlink errors:

Code: [Select]


APP_SOURCES += dhcpc.c


timer.c is compiled as part of the main uip source.

Trev

[hardlink]

Trev wrote:

Here's a Makefile that works for vbcc:

Trev

Thanks!

I gave it a try, but...
Using vbcc makefile:

7.Work:uip/uip-1.0.vbcc/m68k-amigaos> make uip
make: *** No rule to make target `/main.o', needed by `uip'.  Stop.
7.Work:uip/uip-1.0.vbcc/m68k-amigaos>

Okay, I'll give ya a rule, how about this added to Makefile:

main.o: main.c
      $(CC) $(CFLAGS) main.c


7.Work:uip/uip-1.0.vbcc/m68k-amigaos> make main.o
vc -I../uip -I. -lamiga main.c
vbcc V0.8j (c) in 1995-2006 by Volker Barthelmann
vbcc code-generator for m68k/ColdFire V1.6a (c) in 1995-2005 by Volker Barth
elmann
>#include "webserver.h"
error 248 in line 156 of "uip-conf.h": file 'webserver.h' not found
1 error found!
vbccm68k failed returncode 20
vbccm68k  "main.c" -o= "T:t_8_0.asm" -I../uip -I.  -O=1 -Ivincludeos3: faile
d
vc failed returncode 20
make: *** [main.o] Error 20
7.Work:uip/uip-1.0.vbcc/m68k-amigaos>


Okay, who needs a webserver?
-comment out #include "webserver.h" in uip-conf.h;


7.Work:uip/uip-1.0.vbcc/m68k-amigaos> make main.o
vc -I../uip -I. -lamiga main.c
>extern u8_t uip_buf[UIP_BUFSIZE+2+15] __attribute__
warning 54 in line 423 of "uip.h": ; expected
>extern u8_t uip_buf[UIP_BUFSIZE+2+15] __attribute__ ((
error 20 in line 423 of "uip.h": no declarator and no identifier in prototyp
e


Okay, added "#define __attribute__(x)  /*NOTHING*/" in uip.h;


7.Work:uip/uip-1.0.vbcc/m68k-amigaos> make main.o
vc -I../uip -I. -lamiga main.c
>  uip_tcp_appstate_t
warning 56 in line 1185 of "uip.h": } expected
>  uip_tcp_appstate_t appstate;
warning 54 in line 1185 of "uip.h": ; expected
>  uip_tcp_appstate_t appstate;
warning 125 in line 1185 of "uip.h": no declaration-specifier, used int
>}


Okay, 'uip_tcp_appstate_t' only defined in 'hello-world.h' !?!
-referred to in comments in 'uipopt.h'

Any ideas?

[Trev]

It sounds like your version of make doesn't support the -include option. The missing rules are defined ../uip/Makefile.include, ../app/dhcpc/Makefile.include, and ../app/webserver/Makefile.include. The APPS variable tells ../uip/Makefile.include to include each of the application-specific makefiles. Are you using GNU make? If so, which version? If not, you'll have to sort out the makefile options and commands and build one large makefile. Shouldn't be difficult.

Your includes should be (in addition to the OS stuff in vc.config):

-I../uip -I. -I../uip/apps/webserver

Compile and link the following modules:

main.c sana2dev.c clock-arch.c ../uip/uip.c ../uip/uip_arp.c ../uip/uiplib.c ../uip/psock.c ../uip/timer.c ../uip/uip-neighbor.c ../apps/webserver/httpd.c ../apps/webserver/http-strings.c ../apps/webserver/httpd-fs.c ../apps/webserver/httpd-cgi.c

Link with amiga.lib, e.g. -lamiga. It shouldn't work with the minimum startup code, so you're vc.config will need to use the biggy. That's something that needs to be changed to minimize executable size and memory usage. I just couldn't be bother to do all the library management myself when I got started. :-)

The application doesn't do much without the web server. ;-)

I ditched the __attribute__ stuff and switched to an external (defined in sana2dev.c) uip_buf allocated by AllocVec.

uip_tcp_appstate_t should be typedef'd by all the TCP applications in ../apps. (Changing how that works is one of the challenges of making uIP more general purpose, i.e. to allow more than one application. If a bsdsocket.library emulation layer was the application. . . .)

I'll upload some new source code tonight. It should build correctly assuming your version of make likes the makefiles.

Trev

[hardlink]

Trev wrote:
It sounds like your version of make doesn't support the -include option.
Trev

I tried to find the latest version of GNU make on Aminet, and used that; it is version 3.76.1; I'll keep looking.

I also contacted a friend who uses Cubic IDE to ask for assistance, so that may work; I believe Cubic uses the latest GNU tools:

http://developers.xoomwebs.com/

[Trev]

You can download the Cubic IDE compiler package separately. Pretty sure it's stuck in the same Geek Gadgets quagmire as the rest of the community. And up to date port of make would be nice. Apart from that, Cubic IDE (and GoldED in general) is pretty cool.

There's a copy of make 3.81b1 on http://amiga.sourceforge.net, but I haven't used it.

Try changng '-include' to just 'include'. The '-' ignores errors. Perhaps that feature wasn't available in 3.76.1? I don't know enough about make's history to say.

For the curious, I use Visual Studio as my IDE/editor (currently Visual C++ 2008 Express Edition), a makefile project, and Cygwin (as note before) to host the compiler (and make and anything else I might need). I move stuff back and forth between the PC and the Amiga using floppies. (My house is littered with Catweasels, but I'm using FAT floppies at the moment.) I was using Amiga Explorer, but the latest version has some shell extension-related oddities--and it's a pain opening it up and shutting it down on the Amiga side to test the changes to uIP. Floppies are faster.

I tried AmiDevCpp, but the IDE isn't a well-behaved Windows application. Plus, it wouldn't save the option to override the default makefile. And as we saw earlier, there were issues with either the cross-compiler or the startup code. I want to play with uIP and lwIP and not compilers and IDEs, so I switched to vbcc. :-P

Trev

[Colani1200]

Trev wrote:
I move stuff back and forth between the PC and the Amiga using floppies.

Time for a good TCP/IP stack, huh?  :lol:

[Colani1200]

A600 and cnet.device works fine, but quite a few dropped packets...

[mboehmer_e3b]

I was curious, as I selected uIP for a microcontroller project some weeks ago, but didn't start adjusting the code yet.

A4000 + HIGHWAY + NORWAY works also. But: I need to go online with Miami once (and offline again) to get uIP opening the norway.device successfully.
Could be a problem with device initialisation?

uIP seems to be a tick slower than Miami for pings.

How can I add DNS entries?

Anyhow, nice effort from you! Go ahead, it's a promising start.

Michael

[Trev]

@mboehmer_e3b

I certainly do seem to have some issues with device configuration and initialization on a number of different interfaces. I've been out of town for a few days but will be fixing broken things and adding new things tonight and tomorrow.

I believe the slowness in ICMP echo replies is caused by the structure of uIP's event loop and uIP's default checksum calculations. I'll be adding M680x0 optimized checksum routines tomorrow.

I haven't compiled in the DNS resolver, as from the current demo's perspective, it wouldn't be very useful. Is that what you meant? On the remote host (not the Amiga running uIP), adding DNS or hosts entries is system-dependent.

@Colani1200

Dropped packets are probably not a good thing. I'll look into it. I'm going to solve the 100% CPU usage issue as well by moving back to signals and waits; however, they'll work properly this time (they were the cause of dropped packets in the past).

I'll also be bringing the maximum packet size back down to 576 bytes as path MTU discovery hasn't been implemented. This will make the stack more interopable, but if/when SLIP (probable) or PPP (not so probable) support is added, I'll need to look at the impact of the MTU size in general.

Trev

[Trev]

Updates:

The first response to any request (ICMP/TCP/UDP) was dropped in leu of an ARP request if the ARP cache did not contain a mapping for the destination host. This has been resolved [1] by enabling uIP to update the ARP cache whenever a request is received.

1. This may not be the desired behavior (the source hardware address for an IP may not be the same as the destination hardware address for the same IP, i.e. routers, hosts with multiple interfaces, hosts that do transmit load-balancing across a virtual interface, etc.), so I should probably make this an option. If disabled, it would be up to the requesting application to retransmit (TCP) or ignore (ICMP echo and UDP) the unacknowledged or dropped packet, respectively. For now, it's enabled.

More to come....

[Colani1200]

Trev wrote:
Dropped packets are probably not a good thing. I'll look into it.

This appears to be a problem of slower systems (A600). On the 1200 with 030, there were no dropped packets.

[Trev]

If the A600 is taking longer than 1 second (de facto standard delay between requests) to respond to an ICMP echo request, then yes, something will get dropped. I'll need to look at the counter implementation and see what gets ticked as dropped and what gets discarded, i.e. packets that weren't meant for the active uIP process but made it past the link layer.

[Trev]

Thinking out load, it would be nice to have a checksum off-loading device in the Amiga. I see possibilities. It may be possible to use the blitter on slower systems, but I think the CPU will be faster on even slightly upgraded systems. (Thoughts?) 3D chipsets, e.g. Voodoo 3, and advanced processors, e.g. 68060, might be used for vector and superscalar operations.

Anyhow, an optimized checksum routine should suffice. Benchmarks to come over the next few days.

[Colani1200]

Trev wrote:
If the A600 is taking longer than 1 second (de facto standard delay between requests) to respond to an ICMP echo request, then yes, something will get dropped.

I didn't test that with ICMP, but browsed the web pages and the dropped packets were increasing quite quickly.