As an OpenBSD developer I'm very interested in these patches. SeaBIOS is
the only package
left in our ports tree still using lld to link and one of very few ports
not building with Clang. I
just happened to come across your diffs looking to see if anything had
been done in this area
when searching via Google.
This patch series make seabios linkable with lld.
This is beneficial for FreeBSD ports as well
https://svnweb.freebsd.org/ports/head/misc/seabios/Makefile
as they can drop an LLD_UNSAFE
As a maintainer of lld ELF, I have triaged numerous pieces of software.
seabios is the only one making use of
This drops the only instance https://sourceware.org/bugzilla/show_bug.cgi?id=12726
1, 2, 3 and 4 are really independent and can be applied in arbitrary order.
5 depends on 4. I originally combined 4 and 5 and that was why I don't think a patch series made sense.
Fangrui Song (5):
romlayout.S: Add missing SHF_ALLOC flag to .fixedaddr.\addr
Make rom16.o linkable with lld
Makefile: Change ET_EXEC to ET_REL so that lld can link bios.bin.elf
romlayout32flag.lds: Use `. +=` instead of `. =`
test-build.sh: Delete unneeded LD capability test
Makefile | 4 ++++
scripts/layoutrom.py | 13 ++++++++++---
scripts/test-build.sh | 42 +-----------------------------------------
src/romlayout.S | 2 +-
4 files changed, 16 insertions(+), 45 deletions(-)
--
2.26.0.292.g33ef6b2f38-goog
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.
Hi,
This patch series adds support for all HD and QXGA resolutions.
It has been squashed into two commits as per your advice on version 2.
Best regards,
Elliot
Elliot Killick (2):
svgamodes: Add all HD and QXGA resolutions
svgamodes: Improve formatting
vgasrc/svgamodes.c | 217 +++++++++++++++++++++++++++++----------------
1 file changed, 140 insertions(+), 77 deletions(-)
--
2.30.0
Hi Peter. Thanks for the great info.
>> Ok, the main thing is I don't want my OS to have to load
>> this, I want it loaded before the OS is loaded.
> I understood that, and an option ROM satisfies this.
Ok, thanks for confirming.
> The bare board only needs power to run, everything is onboard. Some
> resellers may offer the board mounted in a case.
Ok, I was hoping not to be involved in computers
where even getting a case is a challenge.
>> Does this imply most computers don’t allow their firmware to be
>> flashed with SeaBIOS?
> You can flash it, but the computer will no longer start.
Ok. :-)
> SeaBIOS doesn't perform hardware initialization of e.g. RAM and PCI
> busses.
> SeaBIOS was created to be a coreboot payload when a system with coreboot
> needed a BIOS to start the OS.
Oh I see. In that case, let me rephrase - does this imply most
computers don't allow their firmware to be flashed with
coreboot?
>> If that is the case, is there someone else I should be negotiating with?
> Good question - it probably depends on the bigger picture of your project.
> What do you want to accomplish in the end? Is this a one-off thing or high
> volume, how deterministic must it be in which environment etc.?
I have an operating system already, called PDOS/386,
available at http://pdos.org
It uses the BIOS almost exclusively (switching back
and forth to RM16). I intend to eliminate the
non-BIOS code, and I intend to start using INT 14H
to access the outside world.
But for now, that’s the limits of the design changes
I wish to make to the OS.
I instead want to see if I can make the hardware/firmware
conform to the published specs I rely on, while operating
in a modern environment, with Wifi replacing modems.
And then I want to recommend to anyone purchasing
a computer to pay extra to get one that runs PDOS/386.
Other things they should ensure is that the BIOS can
convert all 3 USB sticks/ports into hard disks, not just the
one that is being booted.
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.
And I don't know what is technically possible, so that
there is something to recommend in the future.
>> > Think of an option ROM as a modular expansion to any BIOS.
>
>> This sounds promising. So perhaps manufacturers allow
>> option ROMs to be flashed, but just not the entire
>> BIOS to be replaced?
> Option ROMs traditionally exist primarily on option cards. SeaBIOS is
> cleverer and can also run option ROMs in the boot flash.
> A proprietary BIOS or UEFI will not likely run an option ROM from the
> boot flash.
I don't need the proprietary one to work, so long as it
can be replaced with coreboot + SeaBIOS.
>> > Here's an open source option ROM: https://github.com/alson/sgabios
>
>> > It's x86 real mode assembly; the typical BIOS environment.
>
>> I took a look thanks. But actually I am hoping all of this will
>> be in C. I was expecting INT 14H to be minimal x86 real
>> mode that switched to UEFI C code,
> Oh, UEFI..
> You may know, but interrupt services such as int 14h are a BIOS interface,
> as provided by traditional BIOS implementations.
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.
> UEFI implementations do
> not provide interrupt services, but a CSM can.
Sure. And there's no disadvantage in CSM, is there?
>> the same as CSM does (right?).
> I don't think UEFI mandates /how/ a CSM implements the interrupt services,
> I'd expect that a CSM can do what it wants without calling into UEFI, but
> depending on what it needs to do it may /want/ to call into UEFI.
Yeah, I'm on the "want" side of that. I'd like to be executing
C-derived code as much as possible.
>> I read that SeaBIOS supports CSM.
> SeaBIOS can act as CSM, at a minimum in VMs, I don't know what the
> situation is with UEFI implementations on hardware.
I don't really understand this. What I'm looking for, at
least ideally, is for a BIOS implementation that switches
to 32-bit or 64-bit mode, and C, to do the actual work.
I thought that was how modern systems worked, and
the very definition of CSM?
>> Ok, for the specific case of converting INT 14H into Bluetooth -
>> I assume that much Bluetooth hardware is proprietary.
> Bluetooth is one of the most, if not the most, proprietary contemporary
> technologies. I think it may be the original case of a quasi-open
> standardization process coupled with fierce intent to keep any
> implementations as closed as possible.
Ok, this is a good starting point for analysis then. The
protocol itself must be open, for two bluetooth devices
to talk to each other. So at what level is it proprietary?
Everyone develops their own silicon?
>> But I know that libbluetooth exists.
> What does libbluetooth refer to, exactly?
> If you mean the shared library (.so file) on Linux systems then that
> isn't relevant for your idea.
Yes, that's what I was referring to. I read that the specs
for bluetooth were buried in the libbluetooth source
code, rather than a document.
>> Basically is it possible to flash libbluetooth onto an option ROM,
>> add 100 lines of x86 assembler to switch to long mode from INT 14H,
>> call libbluetooth, and call it a day?
> No way.
Ok. But that's where my level of understanding is. :-)
>> Or approximately how many lines of x86 assembler and C
>> code are required in addition to what SeaBIOS + libbluetooth
>> already provide? Or is there some technical problem
>> prohibiting this solution?
> The latter. libbluetooth.so is a mere fraction of the software involved
> in using BT on a Linux system. The majority exists in the Linux kernel
> and uses lots of kernel infrastructure, so can not run standalone.
Could it have been modularized so that it could run
standalone? Isn't that what drivers are for? Maybe
if drivers were written to a particular standard they
could be flashed onto the firmware?
> You very likely don't want to get into developing a BT stack, especially
> not one running in a BIOS environment.
I had hoped it already existed, and just needed to be
rearranged and flashed.
The only abnormal thing I wish to do is to get a traditional
INT 14H to call someone else's stack.
> I strongly recommend to keep all BT parts of this project in separate
> hardware outside of the x86 system and to choose/design that hardware
> such that it's comfortable to use in your int 14h handler.
> Since the apu board has two serial ports (one internal on a header)
> its BIOS may already provide int 14h services for those ports, then you
> could just connect a transparent BT UART and be done, no software needed
> at all for that.
The point of my firmware project is not to make BT UARTs
sell like hotcakes. BT is just one target. A more useful one
is Wifi. But I think BT is better for abstracting the problem.
This is a general question about the hardware manufacturing
process.
What options exist for bending hardware (firmware) to the will
of my operating system?
Someone mentioned "SeaBIOS" which is why I'm here, but
I may be in the wrong place.
Obviously I can always go back to 1990 and my OS will work
fine with a real serial port and a real modem.
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.
But I'm only talking about functions 1 (write) and 2 (read)
of INT 14H. I expect function 0 (initialize) to have no meaning
on modern hardware, and should always have been done
via a separate "MODE" command in MSDOS (and now
PDOS/386), and in a modern environment, you can do the
MODE command if you want, and PDOS/386 will dutifully
pass that on to function 0, as MSDOS presumably did, but
(something - SeaBIOS?) will not actually do anything, because
everything (ie the bluetooth hardware) is effectively operating
at N,8,1 and maximum speed.
Thanks. Paul.
Resending ... I thought I was subscribed, but apparently
I am not.
-----Original Message-----
From: Paul Edwards
Sent: Tuesday, June 29, 2021 9:00 AM
To: seabios(a)seabios.org
Subject: Re: INT 14H
Hi Peter.
Thanks for your reply.
> Sure. Implement a driver for that redirection which behaves as an
> int14h handler and place the address of its entry point at address
> 0000:0080. (14h*4)
> The method works with any BIOS.
I would like it to work with any OS that uses INT 14H
(regardless of how many of those exist), rather than
any BIOS.
For now I am happy if it only works with SeaBIOS, and
I will simply buy a PC that allows me to flash SeaBIOS
onto it.
Other manufacturers can do other things with INT 14H,
redirecting it to some other device, such as HAM radio.
> If suitable for your hardware you could do all of it in an option ROM.
I'm not familiar with this terminology. Is this something
that goes into SeaBIOS? I'm expecting it to be something
that is set up (and even configured by the end user in the
BIOS) before my OS is even loaded.
Thanks. Paul.
