Pourquoi ma console série reste muette (null bytes) sur tous les baud rates alors que le câblage est bon ?

Avant de conclure que l’UART est mort, vérifiez que la machine poste. Si le POST ne démarre pas — typiquement à cause d’une RAM incompatible ou mal détectée — le BIOS n’a rien à émettre sur la série : vous ne lisez que du bruit de ligne (0x00/0xFF, erreurs de framing) puis le silence. Une RAM compatible fait réapparaître le POST instantanément.

Comment envoyer la touche F1 à un BIOS via une console série ?

F1 n’est pas un octet unique mais une séquence d’échappement. Sur la plupart des BIOS à redirection série (terminal VT100/ANSI), F1 = ESC O P. Depuis un shell : printf '\033OP' > /dev/ttyUSB0. Le fallback VT220/xterm est ESC [ 1 1 ~ soit printf '\033[11~' > /dev/ttyUSB0.

Pourquoi mon serveur headless reste bloqué au boot après un changement de RAM ?

Beaucoup de BIOS haltent sur Press F1 to resume quand la configuration mémoire change (taille différente), et attendent une touche indéfiniment. Sans écran ni clavier, le serveur ne bootera jamais tant que vous n’envoyez pas F1 — via la console série, c’est la seule porte d’entrée.

Quel pinout pour le header série TTL d’un ReadyNAS RNDU2000 ?

Header 4 broches 3.3V marqué « P » à l’arrière. De gauche à droite : pin1 = GND, pin2 = TX, pin3 = RX, pin4 = VCC 3.3V. Croisez TX/RX vers l’adaptateur (TX→RX, RX→TX), reliez GND, et ne connectez jamais le VCC. Réglage : 115200 8N1, adaptateur sur 3.3V.

Console série muette : c’était la RAM, pas l’UART

Mon NAS (un ReadyNAS RNDU2000 reconverti sous Debian, headless, dans un placard) a un seul slot RAM. Je reçois la barrette pour passer de 1 à 2 Go. Swap, je rallume… et plus rien sur le réseau. Pas de SSH, pas de ping.

Pas de surprise pour qui connaît les vieux BIOS : un changement de taille mémoire déclenche souvent un halt.

Press F1 to resume, F2 to enter SETUP

Sauf que la machine est headless. Pas d’écran, pas de clavier. Le BIOS attend une touche qui ne viendra jamais.

Le faux diagnostic

Restait la console série. Sauf que mes notes disaient « port série mort » : un round de tests précédent avait conclu que le header 4 broches « P » à l’arrière ne sortait que des null bytes à tous les baud rates (1200 → 230400). Adaptateur FTDI pourtant validé en boucle TX↔RX. Hypothèses notées à l’époque : JTAG ? UART propriétaire ? Console désactivée dans le firmware ?

Toutes fausses.

Le détail qui change tout : lors de ces tests précédents, la RAM en place était déjà une barrette incompatible. Et une machine qui ne poste pas n’émet rien sur la série. Le « silence » n’était pas un UART HS — c’était l’absence de POST.

Diagnostic

La chaîne logique, dans l’ordre :

RAM incompatible → le contrôleur mémoire échoue à l’init → le BIOS n’atteint jamais le POST.
Pas de POST → rien à écrire sur la console série → on lit du bruit de ligne (0xFF, 0x00, erreurs de framing) puis le silence.
Conclusion hâtive : « l’UART est mort ». Faux. L’UART attendait juste que quelque chose ait quelque chose à dire.

Avec une barrette compatible (ici DDR2-800 SODIMM, le bon type pour ce chipset), le POST repart, et le port série se met à parler immédiatement à 115200 8N1.

Solution

1. Câbler la console série correctement

Header 4 broches TTL 3.3V marqué « P » à l’arrière. De gauche à droite :

Broche	Signal	Vers l’adaptateur
pin1 (gauche)	GND	GND
pin2	TX (sortie NAS)	RX
pin3	RX (entrée NAS)	TX
pin4 (droite)	VCC 3.3V	NE PAS CONNECTER

Adaptateur USB-UART sur 3.3V (pas 5V, sous peine de griller l’UART), puis :

screen /dev/ttyUSB0 115200

2. Répondre au prompt F1 — en série

F1 n’est pas un caractère ASCII : c’est une séquence d’échappement. Sur un BIOS à redirection série (terminal VT100/ANSI), F1 = ESC O P. Dans screen, la touche F1 envoie déjà cette séquence ; sinon, depuis un autre shell, on l’écrit à la main sur le port :

printf '\033OP'   > /dev/ttyUSB0   # F1 = ESC O P  (VT100/ANSI)
printf '\033[11~' > /dev/ttyUSB0   # fallback VT220/xterm

⚠️ Un seul lecteur à la fois sur le tty. Deux cat/screen ouverts en parallèle se partagent les octets reçus et vous ne lirez que la moitié du flux. L’écriture (printf > /dev/ttyUSB0) reste OK en parallèle d’un lecteur.

3. Valider en SSH

Le boot reprend, le réseau revient :

$ free -h
              total  used  free
Mem:           1.9Gi ...
$ sudo dmidecode -t memory | grep -E 'Maximum Capacity|Size:|Type:|Speed:'
  Maximum Capacity: 2 GB
  Size: 2 GB
  Type: DDR2
  Speed: 800 MT/s

Maximum Capacity: 2 GB + Number Of Devices: 1 : ce chipset plafonne à 2 Go sur un slot unique. La barrette est au maximum supporté, inutile de viser plus gros.

Pourquoi « ESC O P » et pas autre chose

Les touches de fonction n’ont pas de code clavier sur une liaison série : elles sont mappées vers des séquences ANSI/VT. En mode application (SS3), F1–F4 sont ESC O P/Q/R/S ; en VT220, c’est ESC [ 1 1 ~, ESC [ 1 2 ~, etc. Le BIOS choisit l’une ou l’autre selon le type de terminal qu’il croit avoir en face. ESC O P couvre la grande majorité des redirections série BIOS ; gardez ESC [ 11 ~ en second essai.

Lessons learned

Une console série muette n’implique pas un UART mort. Vérifiez d’abord que la machine poste. Pas de POST (RAM, CPU, alim) = rien à émettre = silence légitime.
La RAM incompatible se manifeste par l’absence totale de signal, pas par un message d’erreur lisible — justement parce qu’il n’y a pas encore de console pour l’afficher.
Un serveur headless qui halte sur Press F1 est bloqué pour toujours sans console série. C’est le cas d’usage canonique du port série de debug.
F1 en série = ESC O P (printf '\033OP' > /dev/ttyUSB0), fallback ESC [ 11 ~.
Un seul lecteur par tty. Deux process en lecture simultanée se volent les octets.
Ne jamais brancher le VCC d’un header TTL : GND + TX/RX croisés suffisent, le VCC ne sert qu’à alimenter et grille l’UART s’il est mal apparié.