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 _______________________________________________ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
