I have done further exploration and have a new proposal. I found that USB to serial port adapters are not standardized.
So instead, what about adding NDIS to do USB tethering plus a tcpip stack to create a virtual modem that would allow you to do: ATDnews.eternal-september:119 Then I could connect my Chromebook to my Android phone using the standard cable. Would most of this be able to use existing code? On Thursday, 15 September 2022, Paul Edwards <mutazi...@gmail.com> wrote: > I have a new variation on this problem. > > I have a Chromebook with seabios loaded. > > But the Chromebook doesn't have a serial port. > > I could get a USB to com port adapter. > > But I would like seabios to drive this so that I can use int 14h in my os. > > Is that something that exists or could be added? > > Note that the Chromebook doesn't appear to have an Ethernet port either, > so any solution using that won't work either. > > Thanks. Paul. > > > > On Friday, 6 August 2021, Paul Edwards <mutazi...@gmail.com> wrote: > >> Hi Gerd. >> >> Thanks for your reply. Sorry for the delay, was swamped >> with other things. >> >> Currently I don't know what to recommend, because I >>>> don't understand the other side of the INT 13H/14H, >>>> only the OS side. >>>> >>> >> Well, the other side talks to the hardware, >>> and needs drivers to do so. See src/hw >>> >> >> Surely one can write a serial driver which connects to a remote place >>> using some bluetooth protocol instead of talking to a 16550. That'll >>> be *alot* of work though, you basically have to implement both >>> bluetooth stack and hardware driver. >>> >> >> I expected to assemble, rather than write, such a thing. >> If not from the Linux source code, then FreeBSD or >> ReactOS. >> >> If for some reason (what would that be?) no-one has >> abstracted bluetooth to have a clean interface that I >> could have trivially reused, then I will put aside my >> bluetooth dreams and switch to a different technology. >> How about Wifi? Does that exist in a state usable for >> my purposes? >> >> Sure. For now, I want PDOS/386 to remain traditional. >>>> When I have exhausted everything that is possible >>>> via the BIOS, I will consider adding UEFI support. >>>> >>> >> If you want your firmware provide drivers to you for modern hardware you >>> are in a *much* better position with UEFI. >>> >> >> Well, on some/many/most modern machines there is >> absolutely no other choice - the BIOS doesn't exist, >> even as CSM. >> >> There is a bluetooth >>> protocol specification for example, although I'm not sure how common it >>> is to find an actual uefi driver for bluetooth hardware in the firmware. >>> Talking to ethernet using the firmware-provided uefi driver shouldn't be >>> much of a problem though b/c network boot is a rather standard feature. >>> >> >> Ok, maybe in the medium term I should use a hardware >> device, forget the name, that turns ethernet into Wifi. >> >> So then the problem is reduced to me needing to provide >> a BOOTX64.EFI that converts INT 14H into UEFI ethernet >> calls. >> >> But I'd like to transport all of that software, designed for >>>> that environment, and change nothing at all, and have >>>> it work on a new environment that includes Wifi, bluetooth >>>> and maybe ethernet, and maybe infrared, and maybe >>>> other things I don't know about, but make sense (at >>>> some level) to be accessed via INT 14H. >>>> >>> >> Well. In the server world it is rather common to provide access to the >>> serial line over the network for system management purposes. >>> >> >> One approach for that is to have a separate management controller (bmc), >>> and the serial port of the machine is linked to the management >>> controller instead of a D9 socket. You can then connect to the bmc to >>> manage the machine, and one of the options available is to get serial >>> console access. >>> >> >> Ok, this would allow me to have a BBS. >> >> But not allow me to have a "virtual modem" so that I can >> dial out. >> >> Another approach is to have a virtual 16550 provided by the firmware. >>> Accessing the virtual 16550 will trap into SMM mode where the firmware >>> emulates a serial device and allows to access the serial port remotely >>> over the network, roughly comparable to how qemu provides an virtual >>> 16550 to virtual machines. >>> >> >> Ok, but in the case of qemu I have the same issue - at the end >> of the day I want to drive a modem, so with qemu I can get it >> to talk to a "virtual modem". If the firmware is providing the >> serial to network conversion, I also need to stick in a virtual >> modem there. And that's what I was hoping SeaBIOS would >> allow me to do. >> >> Note that both approaches work at hardware level not int14h level, >>> because modern operating systems use int14h services in bootloaders >>> only if at all. >>> >> >> My operating system, PDOS/386, may not be considered "modern", >> even though it is in active development, but I do wish to use >> INT 14H, as that was the traditional BIOS service provided, and I >> wish to maintain contact with the original 80386 machines. >> >> I expect a modern environment to have the CPU, memory etc >> required to support this basic interface. >> >> BFN. Paul. >> >>
_______________________________________________ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
