From nobody Sat May 23 01:19:08 2026 X-Original-To: questions@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4gMknj50m6z6f0tt for ; Sat, 23 May 2026 01:19:21 +0000 (UTC) (envelope-from polarian@polarian.dev) Received: from mail.polarian.dev (mail.polarian.dev [IPv6:2001:8b0:57a:2385::8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4gMknh1wHzz48J0 for ; Sat, 23 May 2026 01:19:20 +0000 (UTC) (envelope-from polarian@polarian.dev) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=polarian.dev header.s=polarian header.b=DnEQQ6Qs; dmarc=pass (policy=reject) header.from=polarian.dev; spf=pass (mx1.freebsd.org: domain of polarian@polarian.dev designates 2001:8b0:57a:2385::8 as permitted sender) smtp.mailfrom=polarian@polarian.dev DKIM-Signature: v=1; a=rsa-sha256; c=simple/relaxed; d=polarian.dev; s=polarian; t=1779499150; bh=DuJq7Exbde/1fT6Y9d5dUa6+Effocg8krPhe+FkPoiA=; h=Date:From:To:Subject:In-Reply-To:References; b=DnEQQ6Qs+nJjL+zaiBN+K4ws0afdkJOKRmtgdHKrrF3uz6x5hXH2pUOJIcITVNsBe F5TNY6AH5FVf9Atmk1cxWyWr4qW+p/2z53Wh2KaKhc1rFEj8YBgx03i9gqrl/TFc6N Vl/mZ2vGXSr6qlNWnBOk/I0oWEcDkln38W9wtxl4= Date: Sat, 23 May 2026 02:19:08 +0100 From: Polarian To: questions@freebsd.org Subject: Re: Terminal server with consumer hardware Message-ID: <20260523021908.6a3a6240@Hydrogen> In-Reply-To: References: <20260521233422.001d364f@Hydrogen> <20260522154731.4cad8798@Hydrogen> <20260522231322.3a0dbd36@Hydrogen> X-Mailer: Claws Mail 4.4.0 (GTK 3.24.52; amd64-portbld-freebsd15.0) List-Id: User questions List-Archive: https://lists.freebsd.org/archives/freebsd-questions List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-questions@freebsd.org Sender: owner-freebsd-questions@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [-3.47 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.97)[-0.970]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[polarian.dev,reject]; R_SPF_ALLOW(-0.20)[+ip6:2001:8b0:57a:2385::8]; R_DKIM_ALLOW(-0.20)[polarian.dev:s=polarian]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:20712, ipnet:2001:8b0::/34, country:GB]; RCPT_COUNT_ONE(0.00)[1]; MLMMJ_DEST(0.00)[questions@freebsd.org]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[polarian.dev:+] X-Spamd-Bar: --- X-Rspamd-Queue-Id: 4gMknh1wHzz48J0 Hey, > I assume you mean loader.efi(8). Yeah apologies. > While it doesn't specifically say "COM ports only", IMO it essentially > implies that in this table: True, however if the device has a COM port you would assume it would have firmware support for it, its a bit pointless shipping a board with a COM port if it hasn't got firmware for it. So this is why I still find the paragraph mentioning comconsole confusing. Yes you could also imply from the name "comconsole" that it requires a com port. I am 99.99% sure you are right, and I pretty much predicted this from when I started this experiment. However the man page provided some optimism that it would actually be possible, but I think this is just because its ambiguous. > I dunno if that's the final word though, and it's quite possible > things have changed since I last looked. I doubt it, as I mentioned in my original email, this would require the loader to load firmware in order to interface with it. If the COM port is already provided by the firmware as far as I am aware, no device drivers are needed, and that would explain why loader would require a COM port. This isn't the end of the world, as many consumer boards actually still have a JCOM connector, this is not supported by all motherboards (I think especially gaming motherboards drop this header in preference to fit more fan headers and RGB), however desktop orientated boards (budget options) sometimes still have a JCOM header. Provided the firmware would support it, it would therefore be feasible to use a JCOM bracket which would have a DB9 port, this then can be plugged into the terminal server, provided the driver support is there (which, as the terminal server is OpenBSD, is a big if :p) I kinda expected to have to do this once I went from simple serial backup (in case of network lockout) to remotely accessing the boot. Its also feasible to drill some holes into the bracket of the adapter, to run a power switch jumper, and reset jumper through it and then these can be controlled by gpio on RPI, but thats an issue for another day, or a cleaner solution, in theory you can adapt the 5v pin on a molex to a microusb, and then you could run a rpi pico W inside of the case, and then have this connect to a wifi network, which you can in theory provide by the RPI with hostap, and then a small program can run which awaits for a connection and then if it is "RESET" or "POWER" or hell you could do it in binary (0 for power, 1 for reset) and then the corresponding gpio are shorted. And as for power draw, the pico W shouldn't draw more than 0.2W which I don't think is going to run up your energy bills by a lot. Oh and this has the added benefit of a single RPI hostap network in theory could serve a whole rack of servers with pico W in them, although you are limited to 4 USB ports, so 4 serial connections... unless you use a usb hub... But yeah I really do think the loader.efi(8) man page needs some clarification, as we don't want more idiots like me getting confused by it :p Thanks for the help, -- Polarian Jabber/XMPP: polarian@icebound.dev