Tezzeret  1
Tezzeret

Ethernet Startup

This document is about about how the application handles wired Ethernet startup. WiFi startup is a different story, found here: WiFiStartup

Startup may occur differently on different SOCs.

TM4C1294NCPDT SOC

For this chip, this document is mostly about how the application handles Ethernet-related startup, after the core Ethernet functionality is loaded, including setting up specific network daemons, making connections to other systems, etc.

Hardware

This SOC includes the Snow ethernet peripheral, which includes both MAC and PHY.

Core ethernet startup

Core ethernet startup - detecting and linking to the network, getting an IP address from DHCP, etc. - is handled very nicely by TI_RTOS, in a separate network thread that's created by the RTOS out of code in Tezzeret.cfg. That code gives the application a few hooks, for notification or other purposes, but it proceeds on its own, and on its own timing.

The timing questions

When does the application know that the core ethernet startup is complete and that other application prerequisites are satisfied (configuration information is available, etc.), so that the application can do additional network-related startup such as to start daemons, connect to some outside systems, etc.?

When does the application know that some core Ethernet functionality has been lost, in order to shutdown the additional functions?

The timing and ordering of core network startup can not be accurately predicted.

The timing answer

  1. Notice 3 events:
    1. Change of network link status - signalled by hook in network code: "hookLink"
    2. Change in or acquisition of IP address - signalled by hook in network code: " GeoIpAddressAssigned"
    3. Completion of other application code - known by application, at a point near the end of Geometrics::TezzeretApp::Start
  2. When all three conditions are satisfied, add a network-ready event - GM_EVENT_NETWORK_READY_TO_CONFIG - into the application's main, general-purpose event queue.
  3. If any of the conditions becomes invalid, add a network-unavailable event - GM_EVENT_NETWORK_SHUTDOWN - event into the application's main event queue.
  4. In the normal course of event dispatching out of the application's main event queue, when those events are de-queued, the application calls the additional setup and shutdown logic.

Notes

  • For additional information and debugging, look at the function Geometrics::TezzeretApp::NetworkSetupCountdown and the functions that call it, and the functions it calls. It's not complicated.
  • The extra startup and shutdown functions are Geometrics::TezzeretApp::EthernetSetups and Geometrics::TezzeretApp::EthernetShutdown
  • The order of the three signalling events may change, depending on whether the application uses DHCP or static IP addresses, network conditions, etc.
  • The current implementation decrements and increments a counter. Another implementation that uses a mask or separate conditions might also work, but this one seems to be working.

TM4C1292NCPDT SOC

This SOC's peripheral includes a MAC, but not a PHY. Description of startup to follow.