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@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.
Hi Paul,
Paul Edwards wrote:
Resending ... I thought I was subscribed, but apparently I am not.
Okay, including you directly in this reply then.
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.
It works both with any BIOS (int 14h provider) and any OS (that uses int 14h), so is a very general approach.
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.
PC Engines apu hardware comes with coreboot and SeaBIOS, but may or may not fit your application.
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.
Think of an option ROM as a modular expansion to any BIOS.
Any BIOS discovers all option ROMs in a system and then runs them one at a time - indeed late-ish before loading the OS.
There's really no limit to what an option ROM can do to the system. Some are interactive, others aren't, others still are completely invisible.
Some option ROMs you may have come across could be a PXE ROM on a network card, a RAID configuration ROM on a SCSI adapter and the VGA BIOS option ROM on a graphics card.
Here's an open source option ROM: https://github.com/alson/sgabios
It's x86 real mode assembly; the typical BIOS environment.
That code does also interact with int 14h, but pretty much does the opposite of what you want; SGABIOS provides a virtual graphics adapter on a serial port, while you want to provide a virtual serial port doing something specific.
A virtual graphics adapter is fairly complicated so I guess that your end result will be much simpler than SGABIOS is.
Hope this helps
//Peter
Resending ... I thought I was subscribed, but apparently I am not.
Okay, including you directly in this reply then.
Thanks.
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.
It works both with any BIOS (int 14h provider) and any OS (that uses int 14h), so is a very general approach.
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.
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.
PC Engines apu hardware comes with coreboot and SeaBIOS, but may or may not fit your application.
This seems to be a kit. Does this imply most computers don’t allow their firmware to be flashed with SeaBIOS?
If that is the case, is there someone else I should be negotiating with?
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.
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?
Any BIOS discovers all option ROMs in a system and then runs them one at a time - indeed late-ish before loading the OS.
There's really no limit to what an option ROM can do to the system. Some are interactive, others aren't, others still are completely invisible.
Some option ROMs you may have come across could be a PXE ROM on a network card, a RAID configuration ROM on a SCSI adapter and the VGA BIOS option ROM on a graphics card.
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, the same as CSM does (right?). I read that SeaBIOS supports CSM.
That code does also interact with int 14h, but pretty much does the opposite of what you want; SGABIOS provides a virtual graphics adapter on a serial port, while you want to provide a virtual serial port doing something specific.
A virtual graphics adapter is fairly complicated so I guess that your end result will be much simpler than SGABIOS is.
Ok, for the specific case of converting INT 14H into Bluetooth - I assume that much Bluetooth hardware is proprietary. But I know that libbluetooth exists. 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?
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?
Thanks. Paul.
Hi Paul,
Paul Edwards wrote:
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.
It works both with any BIOS (int 14h provider) and any OS (that uses int 14h), so is a very general approach.
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.
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.
PC Engines apu hardware comes with coreboot and SeaBIOS, but may or may not fit your application.
This seems to be a kit.
The bare board only needs power to run, everything is onboard. Some resellers may offer the board mounted in a case.
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.
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.
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.?
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.
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. UEFI implementations do not provide interrupt services, but a CSM can.
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.
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.
A virtual graphics adapter is fairly complicated so I guess that your end result will be much simpler than SGABIOS is.
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.
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.
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.
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.
You very likely don't want to get into developing a BT stack, especially not one running in a BIOS environment.
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.
//Peter
-
Paul Edwards -
Peter Stuge