Startup Trace & Serial Markers
Discord-PXE deliberately emits diagnostics before most of the runtime exists.
The serial stream changes form as the machine progresses:
single-letter stage-1 breadcrumbs
↓
16-bit runtime discovery messages
↓
long-mode / core initialization tags
↓
network + protocol state tags
↓
interactive pxe> shell
For physical hardware, capture serial from power-on at 115200 8N1, no flow control. Starting the terminal after the runtime is already online loses the most useful PXE/TFTP breadcrumbs.
Stage-1 breadcrumb sequence
The tiny stage-1 loader uses single-character markers because it needs a diagnostic path that still works while PXE firmware owns the NIC and the environment is fragile.
A healthy startup progresses through:
A B C D E F 1 3 4 G H I J L M N O P ... Q V R K
The ... represents additional TFTP blocks. Only the first two data blocks get dedicated return/copy markers.
Marker reference
| Marker | Meaning | Reached when |
|---|---|---|
| A | Stage-1 serial/VGA diagnostics are alive | UART initialization and startup diagnostics completed. |
| B | Initial stage-1 checkpoint | Immediate second sanity marker after A; proves the direct debug path can emit repeatedly before PXE discovery. |
| C | About to request the PXE API | Immediately before BIOS INT 1Ah with AX=5650h. |
| D | PXE API call succeeded | BIOS returned the expected PXE API indication. |
| E | PXENV+ validated | Signature/checksum passed and the real-mode PXE entry pointer was saved. |
| F | About to recover cached network state | Immediately before the cached PXE/DHCP handling routine. |
| 1 | Cached-reply probe begins | Stage 1 asks PXE for PXENV_PACKET_TYPE_CACHED_REPLY. This preserves the ROM-specific cached-reply probe used by the proven boot path. |
| 3 | DHCP ACK probe begins | Stage 1 asks PXE for the real PXENV_PACKET_TYPE_DHCP_ACK, which contains the network options needed for the handoff. |
| 4 | DHCP ACK fetch succeeded | The DHCP ACK packet was returned successfully; stage 1 can inspect yiaddr, server/gateway fields, and DHCP options such as subnet, router, and DNS. |
| G | Cached network state recovered/published | Stage 1 has published the collected network state into the handoff and can continue. |
| H | About to load runtime.bin | Enters the runtime TFTP-download path. |
| I | About to issue TFTP OPEN | TFTP parameter block is prepared. |
| J | TFTP OPEN succeeded | Firmware accepted the runtime file open request. |
| L | TFTP block 1 returned | First read call completed successfully. |
| M | TFTP block 1 copied | First returned block was copied into the runtime destination. |
| N | About to request TFTP block 2 | Emitted before the second firmware read call. |
| O | TFTP block 2 returned | Second read call completed successfully. |
| P | TFTP block 2 copied | Second returned block was copied into the runtime destination. |
| Q | Runtime download reached end-of-file | TFTP read loop completed. |
| V | About to close the TFTP session | Emitted immediately before PXENV_TFTP_CLOSE. |
| R | TFTP close succeeded | Firmware accepted the close and guarded PXE memory can be restored. |
| K | load_runtime returned successfully | Stage 1 has the complete runtime image and proceeds toward handoff. |
| X | TFTP close failed | Failure-only marker. |
A marker means that point was reached. The missing next marker is usually more informative than the last marker itself. For example, 1 followed by 3 is normal, 3 without 4 means the real DHCP ACK probe did not succeed, I without J localizes the failure to TFTP OPEN, and N without O localizes it to the second TFTP READ.
The current stage-1 source emits numeric markers 1, 3, and 4. It does not currently emit a 2 checkpoint. The numeric sequence is therefore intentionally non-contiguous.
Reading partial stage-1 traces
Stops after C
A B C
The loader started and serial works, but the BIOS PXE API request did not reach the success checkpoint.
Stops after D
A B C D
The PXE API exists, but PXENV+ validation did not complete successfully.
Stops after F
A B C D E F
The PXE environment was validated, but the cached-network routine did not reach its first internal probe.
Reaches 1, then 3, but not 4
A B C D E F 1 3
The cached-reply probe was attempted and stage 1 moved on to the real DHCP ACK request, but that ACK request did not return successfully. The routine can still publish fallback/default network values, but it did not reach the successful DHCP-ACK parsing checkpoint.
Reaches 4
A B C D E F 1 3 4 G
The real DHCP ACK was returned successfully. Stage 1 can parse the packet fields and DHCP options, publish the resulting handoff, and continue toward the runtime download.
Stops after I
... G H I
The loader entered the runtime-download path but TFTP OPEN did not complete successfully.
Stops after N
... I J L M N
TFTP opened and block 1 transferred correctly. The failure is around the second firmware read call.
Reaches R but not K
... Q V R
The file transfer and TFTP close completed. The remaining failure is between returning from the loader routine and the final successful-load checkpoint.
Stage-1 textual prefixes
| Prefix | Meaning |
|---|---|
[SHARDED-NBP-DEBUG] | Confirms the current stage-1 image actually started. |
[SERIAL/VGA] | Early direct diagnostic output is active. |
[LOAD] | Reports the number of runtime bytes downloaded. |
[BOOT] | Stage 1 is handing control to the larger x64 runtime. |
[ERROR] | Fatal loader failure such as missing PXE API, missing cached boot-server state, or failed runtime download. |
16-bit runtime discovery sequence
After stage 1 jumps into runtime.bin, the larger runtime still begins in 16-bit mode.
The expected discovery sequence includes:
=== DISCORD-PXE SHARDED RUNTIME ===
[UART] BIOS bases=...
[RAM] e820 entries=...
[PXE] PXENV+ version=...
[UNDI] mac=...
[DHCP] cached ip=...
[BOOT16] page tables + long mode transition
[UART]
Reports UART base addresses discovered from the BIOS Data Area.
[RAM]
At this point, reports the number of BIOS E820 memory-map entries. Later [RAM] lines report usable/high-memory state, so read the text after the prefix.
[PXE]
Reports PXE environment state such as the PXENV+ version or later runtime-thunk state.
[UNDI]
Reports PXE UNDI NIC information, including the MAC address.
[DHCP]
Reports cached DHCP state inherited from PXE.
[BOOT16]
Marks page-table setup and the final 16-bit transition toward x86-64 long mode.
x86-64 runtime initialization order
After the far jump into the 64-bit code segment, startup proceeds in a deliberate order.
A representative initialization trace is:
[UARTTEST] ...
[MODE] x86-64 long mode active
[RAM] usable bytes=...
[CPU] ...
[TIME] ...
[HEAP] ...
[PCI] ...
[SMP] ...
[CORE] timers + heap + PCI + multicore services online
[BOOT] crypto init
[RNG] ...
[CRYPTO] ...
[BOOT] crypto ok
[BOOT] pxe thunk init
[PXE] ...
[RTL] ...
[BOOT] tftp files init
[FILE] ...
[BOOT] config init
[CONFIG] ...
[BOOT] net core init
[NET] ...
[BOOT] ip stack init
[IP] ...
[BOOT] tcp init
[TCP] client runtime ready
[BOOT] tcp reliable init
[BOOT] discord init
[DISCORD] runtime base ready, waiting on tls
[BOOT] tls init
[TLS] tls1.2 runtime ready
[BOOT] tls patch init
[BOOT] input init
[INPUT] ...
[BOOT] vfs init
[VFS] ...
[BOOT] shell init
[SHELL] serial + keyboard shell ready
pxe>
[HTTP] ...
[BOOT] runtime init complete
[CORE] legacy runtime online
Some lines are conditional on hardware/configuration and may not appear on every boot, but the subsystem initialization calls occur in this order.
A later subsystem assumes earlier state exists. Gateway output is meaningless if TCP never initialized, and TCP failures are secondary if native/IP networking never became usable.
Runtime log-prefix reference
Platform and core
[UARTTEST]
Direct UART diagnostic output. It can include COM1 line-status/modem-status and loopback results.
[SERIAL-BEACON]
Periodic proof that the runtime is alive and still capable of emitting through COM1.
[SERIAL-LIVE]
Status/control messages for live serial telemetry controlled by the seriallive shell command.
[MODE]
CPU execution-mode state. Normal success is:
[MODE] x86-64 long mode active
[CPU]
CPU runtime initialization and topology: vendor, protections, SSE/FPU/IDT/MSR readiness, and topology details.
[TIME]
TSC calibration. The runtime uses cycles-per-millisecond for deadlines such as heartbeat scheduling, reconnect backoff, and lease expiry.
[HEAP]
General allocator initialization.
[PCI]
PCI enumeration and discovered-device state.
[SMP]
AP/multiprocessor bring-up and worker-dispatch state.
[CORE]
Broad runtime readiness boundaries, including final core-online state.
[FAULT]
x86-64 trap/exception handling. The accompanying vector identifies the exception path entered.
Memory and boot orchestration
[RAM]
Memory discovery and allocation state: E820 count, usable bytes, or high-memory regions depending on phase.
[BOOT]
Top-level subsystem initialization boundary. These lines tell you which initializer is about to run.
If output stops immediately after one [BOOT] ... init line, start with that subsystem.
PXE, NIC, and Ethernet
[PXE]
Runtime PXE thunk state and firmware-service availability.
[RTL]
Native Realtek NIC backend. A normal success line confirms the native polling backend and identifies the detected device.
[NET]
Raw Ethernet/core network state, including ring setup, TX/RX activity, and fallback behavior.
[NETSTAT]
Periodic network statistics/telemetry.
[COM]
Active serial-port base information emitted with live diagnostics.
IP and DNS
[IP]
IPv4 stack configuration and address/routing state.
[DNS]
DNS state for gateway.discord.gg.
Typical progression:
[DNS] starting gateway.discord.gg lookup
[DNS] query sent
[DNS] gateway.discord.gg=...
If lookup starts but query sent never appears, investigate ARP/TX/network readiness first.
TCP
[TCP]
Gateway TCP client state.
Typical progression:
[TCP] client runtime ready
[TCP] starting gateway.discord.gg:443
[TCP] SYN sent
[TCP] gateway connection established
The same prefix reports reset/failure and reliable-transport failure states.
Randomness and cryptography
[RNG]
Hardware RNG readiness. The TLS path depends on usable hardware randomness.
[CRYPTO]
Core cryptographic primitive initialization.
[X509]
Certificate-chain/public-key verification state used by TLS authentication.
TLS
[TLS]
High-level TLS 1.2 state.
Typical progression:
[TLS] tls1.2 runtime ready
[TLS] client hello sent
[TLS] server chose tls1.2 c02f
[TLS] signed x25519 server key received
[TLS] pinned certificate + rsa signature verified
[TLS] client keys + finished sent
[TLS] authenticated tls established
[TLSRX]
Low-level TLS receive-chunk tracing.
[TLSREC]
TLS record-type tracing.
[TLSHS]
TLS handshake-parser state, including the handshake message type currently awaited.
WebSocket and Discord
[WS]
WebSocket HTTP-upgrade transmission state.
[DISCORD]
Discord WebSocket/Gateway state.
Normal progression:
[DISCORD] runtime base ready, waiting on tls
[DISCORD] authenticated tls ready, starting websocket
[DISCORD] http 101 + websocket accept verified
[DISCORD] hello heartbeat-ms=...
[DISCORD] identify sent, token hidden
[DISCORD] READY, bot online
[DISCORD] heartbeat ACK
The same prefix reports close codes, reconnect requests, invalid sessions, malformed Gateway messages, and heartbeat failures.
Runtime files, configuration, input, and shell
[FILE]
Post-boot TFTP file subsystem.
[CONFIG]
Token, trust/pin, and runtime configuration state.
[INPUT]
Keyboard and serial-input subsystem state.
[VFS]
Runtime virtual-file view used by shell commands such as ls and cat.
[SHELL]
Interactive shell initialization/status. Once the runtime prints:
[SHELL] serial + keyboard shell ready
pxe>
the operator has an interactive diagnostic channel even if Discord connectivity later fails.
[HTTP]
Bare-metal diagnostic/control panel HTTP-server state.
Sharding
[SHARD]
Shard scheduler, ownership, allocation, reset, lease, and lifecycle control.
Examples:
[SHARD] context pool ready, max=0x00000080
[SHARD] shard TCP scheduler enabled (stable BSP mode)
[SHARD] live shard ownership plan rebuilt
[SHARD] controller lease expired; shard traffic stopped
Per-shard activity may use [SHARD 0x...].
[SHARDTEST]
Built-in hardware acceptance-test output.
The two-shard success marker is:
[SHARDTEST] PASS: 2/2 isolated shards READY with TLS + heartbeat ACKs
Errors, warnings, and POC state
[ERROR]
Fatal or strongly actionable subsystem failure.
[WARN]
Degraded operation where the runtime may continue on another path.
[POC]
Proof-of-concept-only behavior that is intentionally not part of normal Discord transmission.
End-to-end healthy startup model
stage1 serial alive
A B
PXE firmware API
C -> D -> E
cached PXE/DHCP state
F -> 1 -> 3 -> 4 -> G
runtime TFTP
H -> I -> J
L -> M
N -> O -> P
...remaining blocks...
Q -> V -> R -> K
runtime 16-bit discovery
[UART]
[RAM] e820
[PXE]
[UNDI]
[DHCP]
[BOOT16]
64-bit platform
[UARTTEST]
[MODE]
[RAM]
[CPU]
[TIME]
[HEAP]
[PCI]
[SMP]
[CORE]
runtime services
[BOOT] crypto
[RNG] / [CRYPTO]
[BOOT] pxe thunk
[PXE] / [RTL]
[BOOT] files/config/net/ip/tcp/discord/tls/input/vfs/shell
interactive diagnostics
[SHELL]
pxe>
online protocol path
[DNS]
[TCP]
[X509]
[TLS]
[WS]
[DISCORD] READY
[DISCORD] heartbeat ACK
optional sharded path
[SHARD]
[SHARDTEST]
The first missing transition is normally the best starting point. Do not debug [DISCORD] when [TLS] never became authenticated, do not debug TLS when TCP never reached UP, and do not debug TCP while [RTL] / [IP] state is still broken.
Source
Primary startup and diagnostic strings are implemented in: