July 2021 - SeaBIOS - mail.coreboot.org

[PATCH] fw/coreboot.c: Use coreboot table to find cbfs
by Arthur Heymans April 21, 2022

April 21, 2022

The "cbfs master header" cbfs file is considered a legacy feature in coreboot and is planned for removal in the master branch. Since 2015 the coreboot tables have exported info about the active cbfs. This change uses the cbfs information in the coreboot tables instead of following the cbfs master header pointer in the bootblock to find cbfs. This change makes it possible to access CBFS fmap regions that don't feature a "cbfs master header", which is the case with Googles VBOOT solution. This breaks compatibility with very old coreboot build (build before fb5d5b16 "2015-07-14, cbtable: describe boot media"). Keeping backward compatibility with the "cbfs master header" would complicate the code. Signed-off-by: Arthur Heymans <arthur(a)aheymans.xyz> diff --git a/src/Kconfig b/src/Kconfig index 3a8ffa1..51ba827 100644 --- a/src/Kconfig +++ b/src/Kconfig @@ -93,15 +93,6 @@ endchoice help Support CBFS files compressed using the lzma decompression algorithm. - config CBFS_LOCATION - depends on COREBOOT_FLASH - hex "CBFS memory end location" - default 0 - help - Memory address of where the CBFS data ends. This should - be zero for normal builds. It may be a non-zero value if - the CBFS filesystem is at a non-standard location (eg, - 0xffe00000 if CBFS ends 2Meg below the end of flash). config MULTIBOOT depends on COREBOOT diff --git a/src/fw/coreboot.c b/src/fw/coreboot.c index 7c0954b..8a35c1d 100644 --- a/src/fw/coreboot.c +++ b/src/fw/coreboot.c @@ -88,6 +88,18 @@ struct cbmem_console { #define CBMC_OVERFLOW (1 << 31) static struct cbmem_console *cbcon = NULL; +#define CB_TAG_BOOT_MEDIA_PARAMS 0x30 + +struct cb_boot_media_params { + u32 tag; + u32 size; + /* offsets are relative to start of boot media */ + u64 fmap_offset; + u64 cbfs_offset; + u64 cbfs_size; + u64 boot_media_size; +}; + static u16 ipchksum(char *buf, int count) { @@ -146,7 +158,12 @@ find_cb_subtable(struct cb_header *cbh, u32 tag) struct cb_header * find_cb_table(void) { - struct cb_header *cbh = find_cb_header(0, 0x1000); + static struct cb_header *cbh; + + if (cbh) + return cbh; + + cbh= find_cb_header(0, 0x1000); if (!cbh) return NULL; struct cb_forward *cbf = find_cb_subtable(cbh, CB_TAG_FORWARD); @@ -317,20 +334,8 @@ ulzma(u8 *dst, u32 maxlen, const u8 *src, u32 srclen) * Coreboot flash format ****************************************************************/ -#define CBFS_HEADER_MAGIC 0x4F524243 -#define CBFS_VERSION1 0x31313131 - -struct cbfs_header { - u32 magic; - u32 version; - u32 romsize; - u32 bootblocksize; - u32 align; - u32 offset; - u32 pad[2]; -} PACKED; - #define CBFS_FILE_MAGIC 0x455649484352414cLL // LARCHIVE +#define CBFS_ALIGNMENT 64 struct cbfs_file { u64 magic; @@ -429,30 +434,50 @@ coreboot_cbfs_init(void) if (!CONFIG_COREBOOT_FLASH) return; - struct cbfs_header *hdr = *(void **)(CONFIG_CBFS_LOCATION - 4); - if ((u32)hdr & 0x03) { - dprintf(1, "Invalid CBFS pointer %p\n", hdr); + dprintf(3, "Attempting to initialize coreboot cbfs\n"); + + struct cb_header *cbh = find_cb_table(); + if (!cbh) { + dprintf(1, "cbfs_init: unable to find cb table\n"); return; } - if (CONFIG_CBFS_LOCATION && (u32)hdr > CONFIG_CBFS_LOCATION) - // Looks like the pointer is relative to CONFIG_CBFS_LOCATION - hdr = (void*)hdr + CONFIG_CBFS_LOCATION; - if (hdr->magic != cpu_to_be32(CBFS_HEADER_MAGIC)) { - dprintf(1, "Unable to find CBFS (ptr=%p; got %x not %x)\n" - , hdr, hdr->magic, cpu_to_be32(CBFS_HEADER_MAGIC)); + + struct cb_boot_media_params *cbbmp = + find_cb_subtable(cbh, CB_TAG_BOOT_MEDIA_PARAMS); + + if (!cbbmp) { + dprintf(1, "cbfs_init: unable to find boot media params\n"); return; } - dprintf(1, "Found CBFS header at %p\n", hdr); - u32 romsize = be32_to_cpu(hdr->romsize); - u32 romstart = CONFIG_CBFS_LOCATION - romsize; - struct cbfs_file *fhdr = (void*)romstart + be32_to_cpu(hdr->offset); + const u32 romsize = cbbmp->boot_media_size; + const u32 cbfs_start = cbbmp->cbfs_offset - romsize; + const u32 cbfs_end = cbfs_start + cbbmp->cbfs_size - 1; + + dprintf(3, "cbfs_init: cbfs_start=0x%08x, cbfs_end=0x%08x\n", cbfs_start, + cbfs_end); + + u32 offset = cbfs_start; + for (;;) { - if ((u32)fhdr - romstart > romsize) - break; - u64 magic = fhdr->magic; - if (magic != CBFS_FILE_MAGIC) + if (offset > cbfs_end || offset < cbfs_start) break; + + struct cbfs_file *fhdr = (void*)offset; + + if (fhdr->magic != CBFS_FILE_MAGIC) { + offset++; + offset = ALIGN(offset, CBFS_ALIGNMENT); + continue; + } + + /* Skip empty space */ + if (strcmp(fhdr->filename, "") == 0) { + offset += ALIGN(be32_to_cpu(fhdr->offset) + be32_to_cpu(fhdr->len) + , CBFS_ALIGNMENT); + continue; + } + struct cbfs_romfile_s *cfile = malloc_tmp(sizeof(*cfile)); if (!cfile) { warn_noalloc(); @@ -473,8 +498,8 @@ coreboot_cbfs_init(void) } romfile_add(&cfile->file); - fhdr = (void*)ALIGN((u32)cfile->data + cfile->rawsize - , be32_to_cpu(hdr->align)); + offset = ALIGN((u32)cfile->data + cfile->rawsize + , CBFS_ALIGNMENT); } process_links_file(); -- 2.30.2

4 8

[PATCH v3 0/4] nvme: Add PRP List support
by Alexander Graf Jan. 18, 2022

Jan. 18, 2022

While looking at VM bootup times, we stumbled over the fact that the NVMe code only does I/O operations of up to 4kb at a given point in time. This is usually ok, but if you have an OS that loads a lot of data on boot in combination to network backed storage, it shows in bootup times. There is no need to restrict ourselves to 4kb though. The INT13 call we receive gives us much larger chunks which we can just map into a native bigger NVMe I/O call if the request buffer is page aligned. This patch implements all logic required to do the above and gives a substantial performance boost on boot. v1 -> v2: - fix dprintf - Fix bounds check on PRP list add logic - Reduce PRP list to 15 entries embedded in the ns struct. This reduces BIOS reserved memory footprint by 4kb. v2 -> v3: - new patch: nvme: Split requests by maximum allowed size - Adjust the maximum request size to sector units. The hardware field describes it in pages. Alexander Graf (4): nvme: Record maximum allowed request size nvme: Allow to set PRP2 nvme: Pass large I/O requests as PRP lists nvme: Split requests by maximum allowed size src/hw/nvme-int.h | 16 ++++++- src/hw/nvme.c | 122 +++++++++++++++++++++++++++++++++++++++++++++++------- 2 files changed, 121 insertions(+), 17 deletions(-) -- 2.16.4 Amazon Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B Sitz: Berlin Ust-ID: DE 289 237 879

6 16

[PATCH 00/19] Support SMBIOS 3.0 entry points
by Eduardo Habkost Dec. 18, 2021

Dec. 18, 2021

This series implements support for SMBIOS 3.0 entry points in SeaBIOS. The main advantage of SMBIOS 3.0 entry points is the higher limit for total table size. The SMBIOS 2.1 64435 bytes limit can be easily hit in QEMU if creating virtual machines with more than 720 VCPUs. Eduardo Habkost (19): biostables: copy_fseg_table() function util.h: Delete unused get_smbios_entry_point() prototype smbios: Rename code specific for SMBIOS 2.1 entry points smbios: Generic smbios_next() function smbios: smbios_get_tables() function smbios: Use smbios_get_tables()/smbios_next() at display_uuid() smbios: smbios_major_version()/smbios_minor_version() helpers tpm: Use smbios_get_tables() csm: Don't check SMBios21Addr before calling copy_smbios_21() smbios: Make SMBios21Addr variable static smbios: Use smbios_next() at smbios_romfile_setup() smbios: Extract SMBIOS table building code to separate function smbios: Make smbios_build_tables() more generic smbios: smbios_21_setup_entry_point() function smbios: Make some smbios_build_tables() arguments optional smbios: Make smbios_build_tables() ready for 64-bit tables smbios: copy_smbios_30() function smbios: Support SMBIOS 3.0 entry point at copy_table() smbios: Support SMBIOS 3.0 entry point at smbios_romfile_setup() src/std/smbios.h | 17 ++- src/util.h | 5 +- src/fw/biostables.c | 259 +++++++++++++++++++++++++++++++++----------- src/fw/csm.c | 6 +- src/fw/smbios.c | 12 +- src/tcgbios.c | 12 +- 6 files changed, 227 insertions(+), 84 deletions(-) -- 2.28.0

3 24

[PATCH] vgasrc/svgamodes: added 4k resolution
by vitaly＠cyberhaven.com Dec. 13, 2021

Dec. 13, 2021

From: Vitaly Chipounov <vitaly(a)cyberhaven.com> This requires at least 32MB of video memory. Tested with Windows 10's default display driver and virtio-vga. Signed-off-by: Vitaly Chipounov <vitaly(a)cyberhaven.com> --- vgasrc/bochsvga.h | 4 ++-- vgasrc/svgamodes.c | 1 + 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/vgasrc/bochsvga.h b/vgasrc/bochsvga.h index ae5f75d..f08219f 100644 --- a/vgasrc/bochsvga.h +++ b/vgasrc/bochsvga.h @@ -6,8 +6,8 @@ #define VBE_DISPI_BANK_ADDRESS 0xA0000 #define VBE_DISPI_BANK_SIZE_KB 64 -#define VBE_DISPI_MAX_XRES 2560 -#define VBE_DISPI_MAX_YRES 1600 +#define VBE_DISPI_MAX_XRES 3840 +#define VBE_DISPI_MAX_YRES 2160 #define VBE_DISPI_IOPORT_INDEX 0x01CE #define VBE_DISPI_IOPORT_DATA 0x01CF diff --git a/vgasrc/svgamodes.c b/vgasrc/svgamodes.c index 6e494c7..63ef040 100644 --- a/vgasrc/svgamodes.c +++ b/vgasrc/svgamodes.c @@ -92,5 +92,6 @@ struct generic_svga_mode svga_modes[] VAR16 = { { 0x196, { MM_DIRECT, 2560, 1440, 16, 8, 16, SEG_GRAPH } }, { 0x197, { MM_DIRECT, 2560, 1440, 24, 8, 16, SEG_GRAPH } }, { 0x198, { MM_DIRECT, 2560, 1440, 32, 8, 16, SEG_GRAPH } }, + { 0x199, { MM_DIRECT, 3840, 2160, 32, 8, 16, SEG_GRAPH } }, }; unsigned int svga_mcount VAR16 = ARRAY_SIZE(svga_modes); -- 2.25.1

5 4

[PATCH v3 0/5] Make seabios linkable with lld
by Fangrui Song Aug. 11, 2021

Aug. 11, 2021

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

4 16

[PATCH v2] nvme: don't keep probing namespaces after an active one has been found
by Thanos Makatos July 27, 2021

July 27, 2021

The current implementation keeps probing NVMe namespaces even if an active one has been found. This is unnecessary and most importantly results in memory allocation failure if the are more than a few dozens of namespaces. Also, not probing the remaining namespaces after having found an active one reduces boot time. Signed-off-by: Thanos Makatos <thanos.makatos(a)nutanix.com> --- Changed since v1: * remove unnecessary code changes --- src/hw/nvme.c | 26 ++++++++++++++++++++++---- 1 file changed, 22 insertions(+), 4 deletions(-) diff --git a/src/hw/nvme.c b/src/hw/nvme.c index f035fa2..872ef43 100644 --- a/src/hw/nvme.c +++ b/src/hw/nvme.c @@ -233,9 +233,11 @@ nvme_admin_identify_ns(struct nvme_ctrl *ctrl, u32 ns_id) ns_id)->ns; } -static void +int nvme_probe_ns(struct nvme_ctrl *ctrl, u32 ns_idx, u8 mdts) { + int ret = -1; + u32 ns_id = ns_idx + 1; struct nvme_identify_ns *id = nvme_admin_identify_ns(ctrl, ns_id); @@ -303,9 +305,11 @@ nvme_probe_ns(struct nvme_ctrl *ctrl, u32 ns_idx, u8 mdts) dprintf(3, "%s\n", desc); boot_add_hd(&ns->drive, desc, bootprio_find_pci_device(ctrl->pci)); + ret = 0; free_buffer: free (id); + return ret; } @@ -560,6 +564,13 @@ nvme_wait_csts_rdy(struct nvme_ctrl *ctrl, unsigned rdy) return 0; } +static void +nvme_destroy_io_queues(struct nvme_ctrl *ctrl) +{ + nvme_destroy_sq(&ctrl->io_sq); + nvme_destroy_cq(&ctrl->io_cq); +} + /* Returns 0 on success. */ static int nvme_controller_enable(struct nvme_ctrl *ctrl) @@ -628,15 +639,22 @@ nvme_controller_enable(struct nvme_ctrl *ctrl) goto err_destroy_admin_sq; } - /* Populate namespace IDs */ + /* Find first active namespace. */ int ns_idx; - for (ns_idx = 0; ns_idx < ctrl->ns_count; ns_idx++) { - nvme_probe_ns(ctrl, ns_idx, identify->mdts); + rc = -1; + for (ns_idx = 0; ns_idx < ctrl->ns_count && rc; ns_idx++) { + rc = nvme_probe_ns(ctrl, ns_idx, identify->mdts); + } + if (rc) { + dprintf(3, "no active NVMe namespace\n"); + goto err_destroy_ioq; } dprintf(3, "NVMe initialization complete!\n"); return 0; + err_destroy_ioq: + nvme_destroy_io_queues(ctrl); err_destroy_admin_sq: nvme_destroy_sq(&ctrl->admin_sq); err_destroy_admin_cq: -- 2.22.3

2 1

[PATCH] nvme: don't keep probing namespaces after an active one has been found
by Thanos Makatos July 22, 2021

July 22, 2021

From: Thanos Makatos <thanos(a)nutanix.com> The current implementation keeps probing NVMe namespaces even if an active one has been found. This is unnecessary and most importantly results in memory allocation failure if the are more than a few dozens of nmespaces. Also, not probing the remaining namespaces after having found an active one reduces boot time. I've tested with 1024 namespaces where 512 where active and it worked fined. Signed-off-by: Thanos Makatos <thanos(a)nutanix.com> --- src/hw/nvme.c | 51 +++++++++++++++++++++++++++++++++++++++------------ 1 file changed, 39 insertions(+), 12 deletions(-) diff --git a/src/hw/nvme.c b/src/hw/nvme.c index 746e468..73c1a52 100644 --- a/src/hw/nvme.c +++ b/src/hw/nvme.c @@ -233,9 +233,22 @@ nvme_admin_identify_ns(struct nvme_ctrl *ctrl, u32 ns_id) ns_id)->ns; } -static void +static char* +nvme_ns_desc(const struct nvme_namespace *ns, u32 ns_id) +{ + return znprintf(MAXDESCSIZE, "NVMe NS %u: %llu MiB (%llu %u-byte " + "blocks + %u-byte metadata)\n", + ns_id, (ns->lba_count * ns->block_size) >> 20, + ns->lba_count, ns->block_size, + ns->metadata_size); +} + +/* Returns a pointer to the namespace if it's usable, NULL otherwise. */ +struct nvme_namespace* nvme_probe_ns(struct nvme_ctrl *ctrl, u32 ns_idx, u8 mdts) { + struct nvme_namespace *ns = NULL; + u32 ns_id = ns_idx + 1; struct nvme_identify_ns *id = nvme_admin_identify_ns(ctrl, ns_id); @@ -257,7 +270,7 @@ nvme_probe_ns(struct nvme_ctrl *ctrl, u32 ns_idx, u8 mdts) goto free_buffer; } - struct nvme_namespace *ns = malloc_fseg(sizeof(*ns)); + ns = malloc_fseg(sizeof(*ns)); if (!ns) { warn_noalloc(); goto free_buffer; @@ -277,6 +290,7 @@ nvme_probe_ns(struct nvme_ctrl *ctrl, u32 ns_idx, u8 mdts) buffer size. */ warn_internalerror(); free(ns); + ns = NULL; goto free_buffer; } @@ -296,16 +310,13 @@ nvme_probe_ns(struct nvme_ctrl *ctrl, u32 ns_idx, u8 mdts) ns->dma_buffer = zalloc_page_aligned(&ZoneHigh, NVME_PAGE_SIZE); - char *desc = znprintf(MAXDESCSIZE, "NVMe NS %u: %llu MiB (%llu %u-byte " - "blocks + %u-byte metadata)", - ns_id, (ns->lba_count * ns->block_size) >> 20, - ns->lba_count, ns->block_size, ns->metadata_size); - - dprintf(3, "%s\n", desc); - boot_add_hd(&ns->drive, desc, bootprio_find_pci_device(ctrl->pci)); + char *desc = nvme_ns_desc(ns, ns_id); + dprintf(3, "%s", desc); + free(desc); free_buffer: free (id); + return ns; } @@ -560,6 +571,13 @@ nvme_wait_csts_rdy(struct nvme_ctrl *ctrl, unsigned rdy) return 0; } +static void +nvme_destroy_io_queues(struct nvme_ctrl *ctrl) +{ + nvme_destroy_sq(&ctrl->io_sq); + nvme_destroy_cq(&ctrl->io_cq); +} + /* Returns 0 on success. */ static int nvme_controller_enable(struct nvme_ctrl *ctrl) @@ -628,15 +646,24 @@ nvme_controller_enable(struct nvme_ctrl *ctrl) goto err_destroy_admin_sq; } - /* Populate namespace IDs */ + /* Find first active namespace. */ int ns_idx; - for (ns_idx = 0; ns_idx < ctrl->ns_count; ns_idx++) { - nvme_probe_ns(ctrl, ns_idx, identify->mdts); + struct nvme_namespace *ns = NULL; + for (ns_idx = 0; ns_idx < ctrl->ns_count && !ns; ns_idx++) { + ns = nvme_probe_ns(ctrl, ns_idx, identify->mdts); + } + if (!ns) { + dprintf(3, "no active NVMe namespace\n"); + goto err_destroy_ioq; } + boot_add_hd(&ns->drive, nvme_ns_desc(ns, ns_idx + 1), + bootprio_find_pci_device(ctrl->pci)); dprintf(3, "NVMe initialization complete!\n"); return 0; + err_destroy_ioq: + nvme_destroy_io_queues(ctrl); err_destroy_admin_sq: nvme_destroy_sq(&ctrl->admin_sq); err_destroy_admin_cq: -- 2.22.3

2 4

[PATCH v3 0/2] Add support for all HD and QXGA resolutions
by Elliot Killick July 21, 2021

July 21, 2021

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

2 3

Re: INT 14H
by Paul Edwards July 21, 2021

July 21, 2021

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.

2 1

Re: INT 14H
by Paul Edwards July 12, 2021

July 12, 2021

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.

2 3