Date: Sat, 23 May 2026 02:19:08 +0100 From: Polarian <polarian@polarian.dev> To: questions@freebsd.org Subject: Re: Terminal server with consumer hardware Message-ID: <20260523021908.6a3a6240@Hydrogen> In-Reply-To: <ahDxMJvzBdwf26ts@dragon.home.genyosha.net> References: <20260521233422.001d364f@Hydrogen> <ca6a4d16-9918-4f8d-a198-4f09ff8bba46@dorfdsl.de> <20260522154731.4cad8798@Hydrogen> <ahCMovnPJ6qjU9Nx@dragon.home.genyosha.net> <20260522231322.3a0dbd36@Hydrogen> <ahDxMJvzBdwf26ts@dragon.home.genyosha.net>
index | next in thread | previous in thread | raw e-mail
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.devhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20260523021908.6a3a6240>