>On Tuesday, July 13, 2021 at 11:55:44 PM UTC+10, Scott Lurndal wrote:
>> >> We have a team of a dozen engineers working on ours.
>> >Ok. (Seems like overkill for x86 BIOS, but maybe not for UEFI ...? )
>> Ah, but the "application visible" portion of the BIOS (e.g. the
>> interrupts that Paul is so fond of) is a very, very small part
>> of the BIOS.
>> The vast majority of it is processor-specific code to initailize
>> the hardware (memory controllers, mainboard i2c components,
>> PCI/PCIe controllers (link training, PCI discovery), serializer/deserializers,
>> processor microcode loading, and a hundred other things that
>> most people aren't aware of.
>> >As for what is required to build a new firmware image, I'm assuming
>> >that Paul will start with some open source project like Coreboot
>> >(formerly LinuxBIOS) with SeaBIOS. Some motherboard manufacturers " ...
>> >offer coreboot alongside their standard BIOS ..." according to
>> >Wikipedia, which also lists a UEFI BIOS project, TianoCore, among
>> >others. In other words, if Paul acquires the correct hardware, the
>> >work of programming both the hardware and non-hardware portions of the
>> >BIOS or UEFI are done for him.
>> Those have very limited hardware support. Very limited.
>I don't mind paying more for a computer, but I do need to
>be able to tell someone in the Philippines - go to a computer
>store and ask for a computer with xyz specs so that I will
>be able to flash abc so as to support PDOS/386.
>From my initial investigations, it seems that this "very
>limited hardware support" actually entails "well, there's
>this one thing, but it doesn't even have a case".
You're not paying attention. I'm talking about the hardware
present on the CPU and Southbridge chips. You have to be
able to configure how the CPU routes physical addresses,
for example. The registers that control this are either
private model specific registers (e.g. TOS/TOS2) or
PCI configuration registers on one of the functions on
domain 0 bus 0 (accessed using IN/OUT to CF8/CFC).
Every processor has a difference sequence to initialize
these registers. Each processor has one or more memory
controllers that need to be programmed (also using PCI
configuration space registers on domain 0 bus 0).
Here, for example from an Intel processor:
00:00.0 Host bridge: Intel Corporation 4th Gen Core Processor DRAM Controller (rev 06)
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor PCI Express x16 Controller (rev 06)
00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI (rev 05)
00:16.0 Communication controller: Intel Corporation 8 Series/C220 Series Chipset Family MEI Controller #1 (rev 04)
00:1a.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #2 (rev 05)
00:1b.0 Audio device: Intel Corporation 8 Series/C220 Series Chipset High Definition Audio Controller (rev 05)
00:1c.0 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #1 (rev d5)
00:1c.5 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #6 (rev d5)
00:1c.6 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #7 (rev d5)
00:1d.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #1 (rev 05)
00:1f.0 ISA bridge: Intel Corporation H87 Express LPC Controller (rev 05)
00:1f.2 SATA controller: Intel Corporation 8 Series/C220 Series Chipset Family 6-port SATA Controller 1 [AHCI mode] (rev 05)
00:1f.3 SMBus: Intel Corporation 8 Series/C220 Series Chipset Family SMBus Controller (rev 05)
All of those devices need to be configured, and the configuration
is unique to each CPU.
You don't have the documentation required to performn the
initialization for those (it is chip specific) and it is
not likely that you'll find it in an open source firmware
offering for anything other than a couple of obsolete
Some of that is documented in the corresponding OS/BIOS
writers guide available from the manufacturer, but not
all of it. Particularly the memory controller
>That's not what I'm looking for. I can put up with only
>10% of computers being flashable, or maybe even only
>1%. But computers that don't even have a case don't
>even appear as a count.
>> Not to mention the SMM code - a significant challenge to develop without
>> access to proprietary specifications from the mainboard and processor
>Everything you have said has suggested that the firmware
>But there is such a thing as an "option ROM". I'm not entirely
>sure what that is, but do even 10% or 1% of computers allow
>me to flash one of those?
A legacy PCI device may have an option ROM on the PCI card. This
is generally copied from the PCI card to the firmware/BIOS at
power on by the firmware and slotted into the appropriate
address range (e.g. near 1MB or near 4GB). The address of the
option ROM is stored in the PCI Configuration header for the
device providing the option ROM. This was usually used to
hook the device into the BIOS INT I/O calls.
PCI Express, has deprecated option ROMs.