From: cross@spitfire.i.gajendra.net
In article ,
Scott Lurndal wrote:
>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>In article ,
>>Scott Lurndal wrote:
>>>[snip]
>>>The expansion ROM on PCI was an attempt to remedy this, but clearly
>>>falls short when supporting multiple hardware families (e.g. various
>>>RISC and CISC architectures) pushing the burden to support new
>>>or different operating systems upon the device hardware manufacturer;
>>>which either requires differnent SKUs for each generation of each
>>>supported processor family, a significant burden on the device hardware
>>>manufacturer.
>>
>>I'm going to quibble with this one a little bit.
>>
>>To my mind, modern firmware, including BIOS-like systems,
>>provides three fundamental facilities:
>>
>>1. It provides an abstraction interface for systems software,
>> both the traditional BIOS role, but also a way to decouple
>> emulate legacy hardware interfaces so that hardware
>> advances are decoupled from systems software. Consider
>> running DOS on a machine with a USB keyboard and mouse;
>> "BIOS" gives me a way to emulate an AT or PS/2 keyboard.
>> (Don't get me started on the dumpster fire that is SMM.)
>
>While traditionally it was the case, the firmware component
>(such as it was in the 8088/8086 systems) was a minor portion
>of the BIOS and not generally exposed as an API. The idea
>of a BIOS as a respository of OS driver functionality is the
>idea that I contest.
I am in total agreement with you here. To be clear, I wasn't
trying to refer to traditional BIOSes here so much as address
the bit about option ROMs.
>>2. It's a place to do all sorts of platform enablement. For
>> example, on modern x86 systems, firmware does DRAM timing
>> training, IO bus enumeration and initial allocation and
>> assignment of physical address space for MMIO, bridge
>> assignment and configuration, etc.
>
>This, however, is not generally done via option ROM; consider
>a BIOS as having two components - the hardware initialization
>function and the part that abstracts the device hardware
>from the operating software. I would term the former as
>firmware, and the later as the BIOS conceptually.
Yes. My point was prefatory to discussing why we have option
ROMs and where they fit into the larger ecosystem, and the role
played by firmware on a modern system. To state it succinctly,
I believe that firmware still plays a useful role, beyond the
IO functions of the traditional BIOS. Apologies if that wasn't
sufficiently clear in my earlier post.
>Most modern high-end processors have several small management
>cores (tiny x86 for intel/amd, cortex-m for other vendors)
AMD uses Cortex-A, actually. I'm pretty sure the PSP is an A5
class part. As for the other hidden cores? Who knows. :-(
>that handle the huge amount of hardware setup required before
>the UEFI software gains control. From on-chip ROM initializing
>serial peripheral interface controllers and loading initialization
>firmware into on-chip sram, to initializing all the internal
>address routing functionality (to support programmable bars,
>for instance), initializing on-chip SERDES, ethernet MACs,
>setting clock speeds, enabling clocks, handling trusted boot,
>etc. All happens before the first core leaves the reset
>state. (Unlike x86, which when it left reset started fetching
>from a direct-attached ROM on the LPC bus).
I liken booting a modern CPU to starting up a container ship.
You may initiate the sequence by pushing a button, but it's not
like the enormous 2-story tall cylinders on the marine engines
just start firing right away. Rather, you probably spin up an
electric motor to start a (much smaller) diesel engine that
begins the compression cycle until you've established sufficient
pressure that you can start the big ones, etc.
But at least for AMD, much of the initialization you mention
above really is done on x86.
Initializing the data fabric, CCX init, programming bus speeds,
etc, is all done by AGESA (or whatever replaces it, if you're
not using AGESA; we do that in the host OS at work and have no
AGESA or UEFI on our machines). Actual PCIe training is done
by another of the hidden cores in the SoC complex (one that you
interact with indirectly via the SMU in Milan and earlier; via
MPIO in Genoa and later), but using data structures set up by
software running on x86.
I've always set Ethernet MACs in device drivers, but I guess if
you are trying to boot over Ethernet before x86 comes online
you're back to the bootstrapping problem I mentioned below.
>>3. It solves a necessary bootstrapping problem. Often, an
>> operating system is installed on some storage device that
>> sits on some controller somewhere. But in order to load the
>> OS, I have to be able to initialize and drive the controller
>> "enough" to be able to load the OS (or at least some kind of
>> boot loader that knows to to load the OS). Firmware that
>> understands enough of the platform to do the bare minimum to
>> drive hardware and load a more elaborate bootstrap let's me
>> boot a real system.
>>
>>Options ROMs were meant as part of the solution to last problem:
>>give the hardware enough smarts so that very simple code running
>>in a very constrained early boot environment could get something
>>from the device itself that lets the firmware drive the device
>>well enough to load more capable software from it.
>
>Their primary use was in network interface cards, primarily
>to support PXE boot, in my experience.
Sure, usually poorly and buggily. :-) We had a bunch of dev
boxes in a little cluster that I convinced to boot into iPXE
from USB flash drives; each one would boot a kernel specific to
that machine. So to boot a new test kernel on one of them, you
just copied the kernel to some well-known file name and issued
a command to reset that machine (I built a little
remote-controlled solid-state switch thing using optocouplers,
a programmable LED driver, and a little 8-bit microcontroller,
then wired those in parallel with the machine's reset and power
switches). The UARTs were all connected to a machine somewhere
with USB adapters; so the computer would boot come back, boot
into iPXE from the USB device, then load and run your new
kernel while you monitored the UART remotely. It was a really
nice setup.
But I can still remember buying PCI SCSI adapters in the mid-90s
(perhaps from Adaptec?) that had OpenFirmware ROMs so that you
could boot from them on SPARC. At one point, we had higher
hopes for third-party peripherals, I guess. Now it seems like
most storage controllers are just another IP on the platform.
- Dan C.
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
