OpenCores
URL https://opencores.org/ocsvn/openrisc/openrisc/trunk

Subversion Repositories openrisc

[/] [openrisc/] [trunk/] [rtos/] [ecos-2.0/] [packages/] [devs/] [eth/] [synth/] [ecosynth/] [v2_0/] [host/] [ethernet.tdf] - Blame information for rev 174

Details | Compare with Previous | View Log

Line No. Rev Author Line
1 27 unneback
# Target definition file fragment for ethernet devices.
2
#
3
# The target-side can instantiate up to four ethernet devices,
4
# eth0 to eth3. Each instance requires an entry in the
5
# target definition file specifying what underlying Linux
6
# kernel facility should be used to implement the I/O. This
7
# can take the following forms:
8
#
9
# 1) an existing ethernet device, e.g.
10
#        eth0 real eth1
11
#    thus mapping the eCos device eth0 on to the Linux device eth1.
12
#    The latter network interface must not currently be in use
13
#    by Linux. Traffic will flow to and from the real ethernet, and
14
#    communication is possible with any machine on the LAN.
15
#
16
# 2) the Linux kernel's tap facility.
17
#        eth0 ethertap
18
#    This will result in a Linux ethernet interface such as
19
#    tap3 appearing. The interface can be configured like any
20
#    other network device, for example by using the ifconfig
21
#    command or by creating a configuration file
22
#    /etc/sysconfig/network-scripts/ifcfg-tap3
23
#    The result is a virtual ethernet segment visible only
24
#    to the Linux host and eCos. Bridge software inside the
25
#    Linux host can be used to connect eCos to a larger network.
26
#
27
#    Optionally a specific tap device can be configured,
28
#        eth0 ethertap tap3
29
#    By default the code will pick up the next free tap device,
30
#    usually tap0. If the Linux interface should come up automatically
31
#    then this can be achieved with an ifcfg-tap?? configuration
32
#    file. Explicitly specifying the tap device can avoid some
33
#    confusion.
34
#
35
#    Both the eCos and the Linux network interface need a unique
36
#    MAC address. There is no real ethernet hardware involved to
37
#    supply these addresses, so they have to be invented. The
38
#    Linux kernel will automatically invent one for its interface.
39
#    By default a random MAC address will also be generated for
40
#    the eCos interface, but to make the system more deterministic
41
#    it is possible to specify the MAC address to be used. This
42
#    facility is only available in conjunction with an explicit
43
#    tap device, e.g.:
44
#        eth0 ethertap tap3 00:01:02:03:04:05
45
#    The MAC address should be in the usual format: six 2-digit
46
#    hexadecimal numbers separated by colons. It is the user's
47
#    responsibility to make sure that the address specified
48
#    does not match any other real or invented address visible
49
#    on the local network.
50
#
51
# It is possible that bursts of ethernet traffic occur, causing
52
# packets to arrive faster than they can be forwarded to and
53
# processed by eCos. It is desirable that some number of packets
54
# be buffered, matching the behaviour of many ethernet devices
55
# with built-in fifos. However the number of these packets should
56
# be restricted: if eCos stops accepting ethernet packets or
57
# cannot handle the data quickly enough, then it is possible that
58
# an unlimited number of packets could accumulate in the I/O
59
# auxiliary until all available memory and swap space is exhausted.
60
# By default up to 16 packets will be buffered per device, but
61
# this can be changes with the max_buffer option.
62
#
63
# The ethernet emulation code can perform logging and limited
64
# analysis of each ethernet packet. For example if a particular
65
# packet is an IPv4 ICMP request then details of the request
66
# will be logged to the main text window. The appearance of the
67
# various filters can be controlled here, using the usual
68
# options such as -foreground, -background, and -hide.
69
#
70
# This logging of each ethernet frame can be somewhat time-consuming
71
# and, for a long run, require a lot of memory. Logging can be
72
# disabled by default if desired, and a button on the toolbar allows
73
# this setting to be toggled.
74
#
75
# Ethernet packets can be up to 1514 bytes, so showing entire packets
76
# on a single line can mean very wide lines. In practice the interesting
77
# data is usually at the start, so the output can be truncated to a
78
# maximum number of bytes. The data is displayed in hex so each byte
79
# requires two columns, and some spacing will be added as well to
80
# improve legibility.
81
 
82
synth_device ethernet {
83
    ## Map eCos devices on to Linux ones.
84
 
85
    # eth0 real eth1
86
    # eth0 ethertap
87
    # eth0 ethertap tap3
88
    eth0 ethertap tap3 00:FE:42:63:84:A5
89
 
90
    # eth1 ethertap tap4 00:FE:12:34:56:78
91
    # eth2 ethertap tap5 00:FE:9A:BC:DE:F0
92
    # eth3 real eth2
93
 
94
    ## Maximum number of packets that should be buffered per interface.
95
    ## Default 16
96
    max_buffer 32
97
 
98
    ## Should packets be logged? The default is yes.
99
    # logging  0
100
 
101
    ## Maximum number of data bytes to be shown.
102
    ## Default 64
103
    # max_show 128
104
 
105
    ## Filters for the various recognised protocols.
106
    ## By default all filters are visible and use standard colours.
107
    # filter ether     -hide 0
108
    # filter arp       -hide 1
109
    # filter ipv4      -hide 1
110
    # filter ipv6      -hide 1
111
    # filter icmpv4    -hide 1
112
    # filter icmpv6    -hide 1
113
    # filter udp       -hide 1
114
    # filter tcp       -hide 1
115
    # filter hexdata   -hide 0
116
    # filter asciidata -hide 0
117
}

powered by: WebSVN 2.1.0

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.