Hi Pedro,

Great to meet you and welcome to the TianoCore project! Glad you hear you are interested! A MinPlatform board port can go in two wildly different directions, depending on the answer to one question: Does MinPlatform currently have support for the Processor/Chipset/SoC used by the motherboard?

If yes, then building the new board port only needs to focus on the things that change between each motherboard. For a good example of that of what to expect to be different between motherboards, take a look at the differences between https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel/WhiskeylakeOpenBoardPkg/WhiskeylakeURvp and https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel/WhiskeylakeOpenBoardPkg/UpXtreme.

A few things stick out:


  1.  The WhiskeyLakeURvp has DIMM slots for its DRAM, whereas the UpXtreme board has soldered down DRAM. This changes the methodology for getting the SPD Data (https://en.wikipedia.org/wiki/Serial_presence_detect). For DRAM in DIMM slots, one must read the SPD data by sending read commands over the SMBus (https://en.wikipedia.org/wiki/System_Management_Bus). Each physical DIMM slot will have a different SMBus address where the SPD chip is located, and different motherboards use different addresses. Building the new board port requires the implementer to know what SMBus addresses to use. For an example of this, see the following snippet from https://github.com/tianocore/edk2-platforms/blob/master/Platform/Intel/WhiskeylakeOpenBoardPkg/WhiskeylakeURvp/Library/BoardInitLib/BoardSaInitPreMemLib.c:

PcdSet32S (PcdMrcSpdData, 0);
PcdSet16S (PcdMrcSpdDataSize, 0);
PcdSet8S (PcdMrcSpdAddressTable0, 0xA0);
PcdSet8S (PcdMrcSpdAddressTable1, 0xA2);
PcdSet8S (PcdMrcSpdAddressTable2, 0xA4);
PcdSet8S (PcdMrcSpdAddressTable3, 0xA6);

For soldered down DRAM, typically there is no SPD chip. So the MinPlatform board code needs to carry a copy of the SPD data for the DRAM. That creates the problem that different DRAM vendors need different SPD data, and the motherboard manufacturer will often need to purchase DRAM from more than one memory vendor. To address this, the board code needs some way to detect which memory vendor was used on the current board and choose the correct SPD data. The UpXtreme board port gives a good example of this. Here is the same snippet of code from https://github.com/tianocore/edk2-platforms/blob/master/Platform/Intel/WhiskeylakeOpenBoardPkg/UpXtreme/Library/BoardInitLib/BoardSaInitPreMemLib.c:

BomId = PcdGet8(PcdBoardBomId);
DEBUG ((DEBUG_INFO, "Up Xtreme Bom ID 0x%x\n",BomId));
if ((BomId & BIT1) == BIT1) {
  PcdSet32S (PcdMrcSpdData, (UINTN) mUpXtremeSamsungDdr4Spd);
  PcdSet16S (PcdMrcSpdDataSize, mUpXtremeSamsungDdr4SpdSize);
  DEBUG ((DEBUG_INFO, "Using Xtreme SPD Samsung Ddr4\n"));
} else {
  PcdSet32S (PcdMrcSpdData, (UINTN) mUpXtremeSkhynixDdr4Spd);
  PcdSet16S (PcdMrcSpdDataSize, mUpXtremeSkhynixDdr4SpdSize);
  DEBUG ((DEBUG_INFO, "Using Xtreme SPD Skhynix Ddr4\n"));
}
PcdSet8S (PcdMrcSpdAddressTable0, 0);
PcdSet8S (PcdMrcSpdAddressTable1, 0);
PcdSet8S (PcdMrcSpdAddressTable2, 0);
PcdSet8S (PcdMrcSpdAddressTable3, 0);

In this case, the SMBus addresses are set to zero and the SPD data is provided directly. The board code chooses between the different SPD data payloads based on a BOM (Bill of Materials) identifier. For the UpXtreme, the BomId is initialized by reading the value of 6 GPIO pins and constructing an integer, see https://github.com/tianocore/edk2-platforms/blob/master/Platform/Intel/WhiskeylakeOpenBoardPkg/UpXtreme/Library/BoardInitLib/PeiUpXtremeDetect.c:

// Sample the GPIO pin level
for (Index = 0; Index < NumberOfGpios; Index++) {
  Status = GpioGetInputValue (mUpxGpioBomPad[Index], &GpioData);
  if (EFI_ERROR(Status)) {
    break;
  }
  BomId = (BomId << 1) + (GpioData & 1);
}
if (Index == NumberOfGpios) {
  PcdSet8S(PcdBoardBomId, BomId);
}

  2.  The usage of the GPIO pins provided by the chipset will often vary between motherboard designs. This requires board code to initialize the pins differently. Usually this is done by writing a table describing the GPIO usage for the board. For an example of different GPIO tables for each board, see https://github.com/tianocore/edk2-platforms/blob/master/Platform/Intel/WhiskeylakeOpenBoardPkg/WhiskeylakeURvp/Library/BoardInitLib/GpioTableWhiskeylakeUDdr4Rvp.c and https://github.com/tianocore/edk2-platforms/blob/master/Platform/Intel/WhiskeylakeOpenBoardPkg/UpXtreme/Library/BoardInitLib/GpioTableUpXtreme.c.

  3.  One of the uses of GPIO pins is to provide interrupt signaling, the different GPIO tables will also result in the need for different interrupt routing. This requires the GPIO pins that are used for interrupts to be programmed correctly. And the interrupt routing needs to be reflected in the FADT and MADT ACPI tables. MinPlatformPkg contains the code to generate these ACPI tables based on PCD values: https://github.com/tianocore/edk2-platforms/blob/master/Platform/Intel/MinPlatformPkg/Acpi/AcpiTables/AcpiPlatform.c. But the PCD values may need to be adjusted.

  4.  The policy data provided to the FSP needs to be adjusted according to the board design. Motherboards will have different configurations for the number of PCIe/USB/SATA ports provided. Intel chipsets have a design called “Flex I/O Architecture” (FIA). FIA allows a single HSIO (High Speed I/O) lane to behave as either a USB, PCIe, or SATA lane. Note that a lane in a combination of two pins; two pins are needed for differential voltage signaling. The FIA configuration varies between motherboards, so the configuration needs to be reflected in the FSP input values.

The following Processor/Chipset/SoC are currently supported by MinPlatform, so this type of project would need to choose a motherboard designed for one of these:


  *   Kaby Lake
  *   Whiskey Lake
  *   Comet Lake
  *   Tiger Lake

If MinPlatform currently does NOT support for the Processor/Chipset/SoC used by the motherboard, then a new *OpenBoardPkg will need to be constructed. For the purposes of a GSoC project, I would not recommend attempting this unless the code for the Processor/Chipset/SoC and motherboard already exists somewhere else in TianoCore. Raspberry Pi and Qemu are good examples where this scenario exists, as we already have code to support both of those targets. In that case, Creating the OpenBoardPkg would be an exercise in adapting that existing code to the MinPlatform architecture: https://tianocore-docs.github.io/edk2-MinimumPlatformSpecification/draft/2_architecture/#2-architecture.

MinPlatform is designed to limit the amount of EFI firmware internals you need in order to implement a MinPlatform board port. In general, we try to create generic code that provides those details whenever possible and limit the implementation work to purely the changes needed to get a new motherboard working.

The ACPICA tools are currently only used during the build process to compile the firmware image. They are not executable as UEFI pre-OS applications, which could be useful in some cases. For example, dumping a disassembly of the ACPI code to the UEFI shell might be a useful debugging tool in some cases.

To my knowledge, I don’t believe anyone has worked on the ext2 driver since GSoC 2011. While some progress was made during GSoC 2011, it was not completed. The code from that project is available here: https://github.com/GunioRobot/Ext2Pkg At this point, the filesystem driver would probably need to support ext4 to be really useful. I haven’t done a detailed investigation on how much work that would be. Honestly it should like you might have a better idea of it than I do 😊.

Sorry for the long email, but I hope it helps. Finally I'd like to reiterate... Welcome to the project!

With Best Regards,
Nate

From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Pedro Falcato
Sent: Friday, March 12, 2021 5:08 AM
To: devel@edk2.groups.io
Subject: [edk2-devel] GSoC 2021 (MinPlatform, Ext2, ACPICA, etc)

Hi everyone!

I'm Pedro Falcato, a student from FCT Nova in Lisbon, Portugal. I've gotten a bunch of experience over the years with C/C++, x86 in general and UEFI/ACPI with my hobby OS/kernel development, and I've got to say, I'm quite interested in some of the projects you've got here.

So, a few questions:

1) What entails building a MinPlatform board port for any board whatsoever? I've seen Kaaira wants to do the Qemu port, I would love to do something like that but for the RPi or some real motherboard, but I fear it might be too difficult?

2) How much knowledge of EFI firmware internals do you need? With my EFI bootloader development over the years I already have a firm hand on how the external-facing API looks like, but I have to say I haven't really read the parts of the spec that describe the driver and internal APIs, so to speak.

3) Isn't there already an ACPICA port for UEFI environments? What stops us from going one step further and also build the rest of the "user-space" utilities?

4) How's the status of the ext2 driver? How different do Tianocore filesystem implementations look from the standard-ish kernel interfaces you can see in Linux, *BSD, etc? I'm also quite interested in this one because I've written a read/write ext2 driver before, so the concepts are kind-of fresh in my head.

I hope you folks can answer my questions so I can figure out what project I want to work on! :)

Looking forward to working in Tianocore!

Thanks,
Pedro Falcato