EMAC changes broke PPP glue - fix it up. In particular, PPP steals
the netif->state pointer, so we can't use it as a back pointer to
our LWIP::Interface.
There is a configuration problem with UBLOX_C027 cellular because of missing
LWIP memory configuration for the target.
Added configuration for LPC1768, LPC4088, LPC4088_DM targets and changed
NXP to more specific LPC546XX.
- Set network stack to store event queue so that mbed::mbed_event_queue() call
is not needed every time call_in() is called
- Added dns state variables and enum (states are: created, initiated and cancelled)
- Corrected DNS response handling so that if DNS server returns that host name is
unknown the DNS query is not tried again
- Reorder mutexes in nsapi_dns_query_multiple_async()
- Created nsapi_dns_query_async_initiate_next() function to initiate the next
DNS query from the queue after delete of previous query
- Added dsn_timer_running variable to supervise DNS timer start/stop
- Changed cancel function to only mark query as deleted and moved deletion
to timer function. This allows to run socket close on DNS thread
- Added new nsapi error NSAPI_ERROR_TIMEOUT for DNS (and other) timeouts
- Changed call_in/call methods of the stack to callback provided by the stack
- Specified what are limitations for operations that are made in callback
- Added pure virtual class DNS that defines DNS operations
- Added cancel operation and unique ID to DNS request used in cancel
- Added DNS configuration options to netsocket/mbed_lib.json for retries,
response wait time and cache size
- Changed host name to use dynamic memory in DNS query list and cache,
set maximum length for the name to 255 bytes.
- Added mutex to asynchronous DNS
- Reworked retries: there is now total retry count and a server specific count
- Ignores invalid incoming UDP socket messages (DNS header is not valid), and retries DNS query
- Reworked DNS module asynchronous operation functions
- Corrected other review issues (nothrow new, missing free, missing mutex unlock etc.)
- Added non-blocking DNS interface to network interface and
network stack.
- Added caching of DNS replies.
- Added a network stack function to get DNS addresses from stack.
- Added call and call_in hooks to onboard network stack to
allow calling functions from onboard stack context.
- Added support to call and call_in functions to LWIP and
Nanostack.
- Disabled LWIP DNS translator with the exception of DNS
address storage used in DNS address get.
Initial work by Bartek Szatkowski in https://github.com/ARMmbed/mbed-os/pull/4079,
reworked following review of https://github.com/ARMmbed/mbed-os/pull/5202 to
transform the entire system into C++, retaining the basic functionality.
Bartek's summary:
* Porting ethernet to EMAC
* Updating EMAC to enable multiple interfaces
* Untangling networking classes, making the abstractions a bit clearer to follow, etc
* General refactoring
* Removal of DEVICE_EMAC flag and introducing DEVICE_ETH and DEVICE_WIFI
Revisions since initial branch:
* Remove lwip depencies
* Correct doxygen warnings
* Remove emac_api.h, replace with C++ EMAC abstract class.
* Create OnboardNetworkInterface, and LWIP implementation.
* Mappings since #4079
lwip-interface/nsapi_stack_lwip.c -> LWIPStack.cpp
lwip-interface/ipstack_lwip.c -> LWIPInterface.cpp
netsocket/mbed_ipstack.h -> OnboardNetworkStack.h
hal/emac_api.h -> EMAC.h
* Reinstate use of EthInterface abstraction
* Correct and clarify HW address EMAC ops
* Restore MBED_MAC_ADDR implementation
* Integrate PPP support with LWIP::Interface.
* Convert K64F lwIP driver to K64F_EMAC.
To do:
* Convert emac_stack_mem.h to follow this pattern.
* Figure out DEVICE_ETH/EMAC
* Update all drivers to use EMAC
Our config file for lwIP had TCP_QUEUE_OOSEQ disabled - this can
cause significant performance problems, as observed during testing.
One lost packet can lock an input stream into a mode where the
transmitter keeps thinking packets are being lost, so keeps slowing
down. This caused test failures - a transfer that would normally
take 10s hit a 60s timeout.
Turning this on increases code size, but doesn't significantly increase
static memory use. The memory used for out-of-order packets comes from
the same pbuf pool as for outgoing TCP segments, so there is contention
when running bidirectionally.
Out-of-order processing is on by default for lwIP - this seems to be
another example of us excessively paring it back.
Nanostack related files moved under 'feature/nanostack'
Common libraries moved to 'features/frameworks'
Allow FEATURE_COMMON_PAL still to be defined in the build so
that we don't break any builds.
lwIP was using us_ticker unnecessarily, complicating the code and
potentially causing grief with power saving, and possible glitches
on timer wrap. Switch it to use the RTOS tick count.
Compile: lwip_stack.c
In file included from ../features/FEATURE_LWIP/lwip-interface/lwip_stack.c:41:0:
../features/FEATURE_LWIP/lwip-interface/lwip_stack.c: In function 'mbed_lwip_bringup_2':
../features/FEATURE_LWIP/lwip-interface/ppp_lwip.h:58:44: warning: statement with no effect [-Wunused-value]
#define ppp_lwip_disconnect() ERR_IF
^
../features/FEATURE_LWIP/lwip-interface/lwip_stack.c:858:21: note: in expansion of macro 'ppp_lwip_disconnect'
ppp_lwip_disconnect();
^~~~~~~~~~~~~~~~~~~
../features/FEATURE_LWIP/lwip-interface/ppp_lwip.h:58:44: warning: statement with no effect [-Wunused-value]
#define ppp_lwip_disconnect() ERR_IF
^
../features/FEATURE_LWIP/lwip-interface/lwip_stack.c:875:21: note: in expansion of macro 'ppp_lwip_disconnect'
ppp_lwip_disconnect();
^~~~~~~~~~~~~~~~~~~
Glue code was inspecting lwIP's netconn "type", checking directly for
NETCONN_UDP and NETCONN_TCP.
Unfortunately the type byte has some flag bits like
"IPv6", which means the tests fail if it's an IPv6 socket. So, for
example, TCP socket options were rejected for IPv6.
Add the necessary NETCONNTYPE_GROUP macros to fix this.
This patch changes the way data is put in the TX_DATA_PORT register when
sending packet over Ethernet.
When this driver is compiled with release compilation profile
(space optimization compiler options) with Arm compiler version 5,
the line:
SMSC9220->TX_DATA_PORT = *pktptr;
generates the assembly instruction to get the pktptr pointed value:
LDM r2!, {r3}
with pktptr = r2
However, the code does not prevent the pktptr value from being unaligned
(to a 32 bits boundary) in that zone and the LDM instruction causes a
HardFault if this is the case. When the compiler option is not activated
(debug and develop compilation profiles), the compiler generates LDR
instruction instead which does not cause a HardFault.
The ARM v7-M states page B3-601: "Unaligned load-store multiples and
word or halfword exclusive accesses always fault."
To face that problem, we check if the data pointer is aligned or not. If
it is, we apply the same algorithm than before. If not, a local variable
is created and we copy in it, byte per byte, the contents at the
unaligned pointer. However, it will impact performances adding 8
instructions (one LD and one ST for each copied byte).
Change-Id: I11f6e82ce5521960d2ecf499f718f76fec29c0b0
Signed-off-by: Hugues de Valon <hugues.devalon@arm.com>
This patch fixes a memory bug. `eth_arch_enetif_init` method call
would attempt to write to un-initialized area of memory.
Change-Id: I9881de71d58fa14db609fe3e24617a210b896471
Signed-off-by: Galanakis, Minos <minos.galanakis@arm.com>
I added the function declarations of Ethernet functions that have a WEAK attribute. Although several Ethernet functions was called in rza1_emac.c, GR-LYCHEE don't have Ethernert feature. But there may be case that GR-LYCHEE uses LWIP feature.
In this case, since GR-LYCHEE will occur the build error, I addressed the error by defining the functions with a WEAK attribute. For reason of WEAK attribute, there is no influence in GR-PEACH and VK_RZ_A1H that have Ethernet feature.