From: cross@spitfire.i.gajendra.net
In article ,
Scott Lurndal wrote:
>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>>In article ,
>>Scott Lurndal wrote:
>>>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>>>In article ,
>
>>
>>>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. :-(\
>
>Ah, thanks. I've been out of the AMD world for a decade now,
>building ARM64-based SoCs.
Consider me jealous. :-)
>
>>
>>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.
>
>Ah, yes, I do recall AGESA - although when we were building
>AMD systems, we contracted with Supermicro to do the BIOS;
>AMD open-sourced AGESA just after we (3Leaf Systems) shut down.
Yeah. It was open for a brief, shining moment, and then they
brought it back in and closed the source. ISVs can get access
to it under NDA, but it's only useful as a reference, really.
You _can_ build an actual firmware image by overlayering it onto
with, but it requires a lot of tinkering to get something that
will actually boot a real OS.
The PoR, as I understand it, is to release 6th gen Zen (Venice
maybe?) with UEFI built on openSIL, which is sort of like open
source AGESA. I think they'll use EDKII for the UEFI bits.
https://github.com/openSIL/openSIL
>>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.
>
>Sure, even on our SoCs, much of the ethernet MAC configuration
>is done in the driver. The parts between the MAC and the
>port (assigning SERDES lanes to PCI controllers (x1, x4, x8),
>initializing the SERDES, assigning MAC address, etc.) are
>done by the firmware.
Yeah. AGESA does that on AMD. Well, it sets some data in RAM
and DMAs it over to either the SMU or MPIO which use it to
configure DXIO.
E.g.,
https://github.com/openSIL/openSIL/blob/3000c3227a015d649298ce5d
bc804905e243060/xUSL/Mpio/Common/MpioInitFlow.c#L508
>Plus, as you note, the firmware may have a TCP/IP stack
>that requires MAC initialization to support PXE.
I feel like this is where Ron Minnich's LinuxBoot stuff works
well. Replace the UEFI DXE layer with a copy of Linux and a
small userspace written in a type- and memory-safe language.
You've got a real IP stack and can do DHCP and use TCP to load
and kexec your real OS.
>>>>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. :-)
>
>Indeed.
>
>> 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.
>
>What was missing was a standard driver interface for SCSI
>similar to the later AHCI for SATA (and UHCI/EHCI/xHCI for
>USB). Even those standard driver interfaces often require
>firmware initialization to enable (and sometimes fully support).
Yeah. It's like the SCSI folks had a good standard for the
peripheral side, and PCIe gives us a good IO architecture on the
host side, but they totally missed a standardized controller
interface. That, and cost, hurt adoption.
>> 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.
>
>Yup, and most new device classes have standardized driver interfaces
>(e.g. NVMe).
Yeah, that's a really good point.
- Dan C.
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
