Ethereal Wake

Even worse than the original MII, GMII used too many pins. For full tri-mode (10/100/1000) operation, a full 25 were required. This is becoming problematic not only for switches, but ordinary processors and FPGAs.

As when the RMII Consortium formed to produce RMII, a group of silicon makers got together to produce a Reduced Gigabit Media Independent Interface (RGMII). Since this was performed external to the ethernet working group, this interface will not be found in IEEE 802.3. The standard needs to be sourced separately. With distribution largely unrestricted, copies of the standard are mirrored locally: RGMII Version 1.3, Version 2.0.

When introducing Gigabit Ethernet, there was a problem adopting the existing MII. Simply increasing the clock speed another order of magnitude would bring it to 250 MHz and a period of 4 ns. This introduced two issues: First, the clock speed would be well in excess of those used by commodity memory buses of the time, making it difficult to implement. Second, the system synchronous design of the transmit path would make it impossible to control setup and hold timing.

One of the early complaints about MII was that it used too many pins. For a switch ASIC and external PHYs, it would require sixteen pins and two clock domains per port. For an eight port switch, that’s 128 pins and sixteen clock domains before power and other considerations. As silicon became cheaper, packaging started to be the dominant cost for low-end integrated circuits. In order to keep costs down, they needed a way to reduce the number of pins.

With Fast Ethernet, Ethernet introduced something new. Previously, the Physical Signaling layer was integrated into the MAC and connected to the actual media through a Media Attachment Unit. While the user could switch between twisted pair (10Base-T), thinnet (10Base2), thicknet (10Base5), or even fiber (10Base-F) simply by changing MAUs, switching to a different encoding (e.g. Fast Ethernet) would require a completely new interface.

Instead of requiring new networking equipment to manage the PCS of each individual protocol, the MAC communicates with the PHY with a Media Independent Interface (MII). Now, free of protocol-specific encodings, different line rates and protocols could be selected by simply switching between different PHYs, leaving the MAC unaffected. While interchangeable PHYs is now the domain of high-end networking (e.g. SFP modules), the MII interface and its derivatives are the primary mechanism for connecting integrated MACs (and FPGAs) to commodity Ethernet transceivers.

In this first article in a series on Ethernet, I will be focusing on the fundamentals of Ethernet, such as packet structure, check sequences, and flow control. Much of the information will be conceptual but referenced repeatedly when discussing specific protocols.

Note: The most recent version of the 802 standards are available from the IEEE Get program at no cost. It is highly advised that anyone working with Ethernet download a copy of 802.3 (Wired Ethernet).

For many industrial embedded projects, embedding debugging support (e.g. JTAG) into the design can be immensely useful. This can be for the convenience of integrated debugging or specialized needs, such as galvanic isolation. The FTDI family of High-Speed USB-Serial transceivers are commonly used for this purpose. FTDI’s Multi-Protocol Synchronous Serial Engine (MPSSE) can offload the JTAG state machine and achieve clock speeds as high as 30 MHz. Software like OpenOCD provides a solid basis for manipulating microcontrollers but the situation is very different when it comes to FPGAs.

When writing a freestanding application, it’s generally necessary for the firmware engineer to handle runtime initialization. Even when a library like newlib includes a rudimentary implementation of crt0.o, initialization is a very application-specific process owing to the need to initialize hardware, memory, and other loading tasks.

In this essay, we examine the current and historical implementation of executable initialization, finishing with a minimal implementation usable with firmware applications.

Note: Most firmware applications need to address the initialization of .data and .bss from nonvolatile memory. That is not addressed in this essay.

While self-hosting Git isn’t that hard (all you need is a shell accessible through SSH), some tools make it easier. One of them is Gitea, a nice, self-contained Go binary that provides you a GitHub clone without all the complexity and dependency hell of something like GitLab. One of the things it does not provide is an integrated continuous integration/delivery (CI/CD) platform. Instead, it implements the same basic patterns at GitHub allowing for pairing with a range of third-party services, cloud or hosted.

Bazel is one of the least terrible build systems out there. It can handle large codebases, mixed languages, and cross-platform builds like a champ. Unfortunately, it suffers from rather poor documentation with an enterprise Java codebase that is a nightmare to decipher.

One of the features I’ve been trying to make use of are linkstamps. The idea behind linkstamps is to embed information such as the Git commit identifier into the resulting binary, providing direct traceability for deployed binaries. Unfortunately, regarding this feature, Bazel suffers from the common documentation anti-pattern where they describe what an option is, not what it does.

When using FreeBSD, the most common method for virtualization and process isolation are jails. Introduced with FreeBSD 4.0 in March of 2000, they predate the closest Linux equivalent, cgroups (and, by extension, Docker), by nearly a decade.

A core part of any virtualization technology is its interaction with the networking infrastructure. In this regard, I’ve found much of the available documentation lacking, often deferring to third party tools which are no longer maintained. As such, I’ve had to scrape multiple sources and reverse engineer system programs to figure out how it’s put together.