EDK2: new support for ASRock Rack ALTRAD8UD-1L2T / ALTRAD8UD2-1L2Q and build improvements for Mt Jade and COM-HPC-ALT

Last night I merged a large set of changes into TianoCore’s edk2-platforms repo.

Among them were commits to add support for ASRock Rack’s ALTRAD8UD-1L2T and ALTRAD8UD2-1L2Q boards, and improvements to the new build script, buildfw.sh which affect builds of firmware for Ampere’s Mt Jade and ADLINK’s COM-HPC-ALT (AADP, AADK, AADR) platforms too.

I added buildfw.sh because I didn’t find the scripts in the edk2-ampere-tools repo to be very user-friendly. buildfw.sh can be used whether you have access to the TF-A (ATF) binaries or not.

If you don’t have them, you’ll see the following message at the end of the build:

Warning: the TF-A (Trusted Firmware) binary wasn’t found. Only the UEFI firmware was built.
Done. Firmware is in Build/<PlatformName>/.

You can use this firmware by reading out the existing BIOS/UEFI SPI-NOR, dd’ing the new firmware into the correct location and then writing the file back to the EEPROM.

Another optional binary is the Renesas USB controller firmware, K2026090.mem.
It’s freely available, but if you choose not to use it you’ll see the following message at the end of the build:

Warning: the Renesas UPD720202 USB3 Controller firmware file $HOME/src/uefi/K2026090.mem was not found.
The firmware was built without the firmware. The USB3 controller will not work unless the firmware is loaded in the OS.
See edk2-platforms/Drivers/OptionRomPkg/RenesasFirmwarePD720202/README.md for details on how to obtain it.

To build the firmware, run buildfw.sh:

./edk2-platforms/Platform/Ampere/buildfw.sh  --help
Usage:
  ./edk2-platforms/Platform/Ampere/buildfw.sh [options]

Options:
  -b <bldtype>, --build <bldtype>  Specify the build type: DEBUG or RELEASE
  -t <tc>, --toolchain <tc>        Specify the toolchain to use: GCC or CLANG
  -m <mfg>, --manufacturer <mfg>   Specify platform manufacturer (e.g. Ampere)
  -p <plat>, --platform <plat>     Specify platform to build (e.g. Jade)
  -l <kern>, --linuxboot <kern>    Build LinuxBoot firmware instead of full EDK2 with UEFI Shell, specifying path to flashkernel
  -f, --flash                      Copy firmware to BMC and flash firmware (keeping EFI variables and NVPARAMs) after building
  -F, --full-flash                 Copy firmware to BMC and flash full EEPROM (resetting EFI variables and NVPARAMs) after building

  Note: flash options require bmc.sh file with env vars BMC_HOST, BMC_USER and BMC_PASS defined

  Available manufacturers:
    ADLINK
    Ampere
    ASRockRack

  Available platforms:
    ADLINK     -> ComHpcAlt
    Ampere     -> Jade
    ASRockRack -> Altra1L2Q
    ASRockRack -> Altra1L2T

Environment Variables:
  SECUREBOOT_DIR       - directory to store SecureBoot keys, certs etc.
  USE_EXISTING_SB_KEYS - use existing Secure Boot Platform and Update keys
  DOWNLOAD_MS_SB_KEYS  - force re-download of Microsoft Secure Boot KEK and DB certificates
  CERT_PASSWORD        - password to use when generating Platform and Update Keys and certificates
                         defaults to "password" if not specified.

  EDK2_SECURE_BOOT_ENABLE             (TRUE)
  EDK2_NETWORK_ENABLE                 (TRUE)
  EDK2_INCLUDE_TFTP_COMMAND           (TRUE)
  EDK2_NETWORK_IP6_ENABLE             (TRUE)
  EDK2_NETWORK_ALLOW_HTTP_CONNECTIONS (FALSE)
  EDK2_NETWORK_TLS_ENABLE             (TRUE)
  EDK2_REDFISH_ENABLE                 (TRUE)
  EDK2_PERFORMANCE_MEASUREMENT_ENABLE (FALSE)
  EDK2_TPM2_ENABLE                    (TRUE)
  EDK2_HEAP_GUARD_ENABLE              (FALSE)
  EDK2_X86_EMULATOR_ENABLE            (TRUE)
  EDK2_SHELL_ENABLE                   (TRUE)

Other improvements are the build-time generation of ./edk2-platforms/Platform/<Manufacturer>/<Platform>Pkg/Capsule/SystemFirmwareDescriptor/HostFwInfo.h - this contains the firmware version generated from the current date combined with the build number (which is stored in the file .fw_bld). This means the version is now monotonically increasing and the Linux fwupdmgr tool can be used to initiate the firmware upgrade by running fwupdmgr install <firmware-filename.cab>. Run fwupdmgr get-details <firmware-filename.cab> to see information about the currently installed firmware and the firmware in the file specified.

I’ve also changed the way Secure Boot and Capsule updates are done: instead of using test keys from e.g. edk2/BaseTools/Source/Python/Pkcs7Sign/, I added edk2-platforms/Platform/Ampere/Tools/GenerateSecureBootKeys.sh which generates fresh keys during the build and downloads the set of Microsoft certificates for Windows.
Set USE_EXISTING_SB_KEYS to prevent that automatic generation process and use existing keys in the secureboot_objects directory.

6 Likes

@cltran any of this helpful to you as well?

Actually, I was the guy who participated into the review and granted approval for Rebecca’s PR so I know what the changes are :D.

I am reviewing buildfw.sh again to make sure that other platforms can benefit from that script with minimal changes required, or we can improve it for wider usage. As you can see, the script can only builds EDK2 firmware for “Available platforms” while comparing with edk2-ampere-tools/Makefile, it supports building firmware for any board if the package follows naming conventions in Platform/Ampere package (like JadePkg).

3 Likes

NICE!

I not booted ASRockRack Altra1L2T yet (some parts did not arrived yet) but I am going to use this for sure.

How much does it differ from whatever is provided by AsrockRack?

1 Like

The script doesn’t only support the listed platforms! I just added that because the script is in Platform/Ampere but also supports Platform/ADLINK and Platform/ASRockRack which probably isn’t obvious. It supports any platform which follows the naming conventions.

2 Likes

@hrw ASRock Rack provides firmware that uses AMI Aptio which is obviously proprietary. That’s the big difference between them.

2 Likes

Oh. I thought it is not. Thanks for pointing it out! Let me see if I can adapt the script for other boards and get rid of using ampere-edk2-tools. By the way, regarding the new feature to store tiny OS in UEFI_EXTRA region, we need to support to build LINUXBOOT_IN_UEFI_EXTRA firmware with the script.

Thank you for your hard work on this! I’m excited to try this out (and hopefully not screw up and brick my ASRock motherboard :sweat_smile:.) Excited to hopefully get gpu oproms working on my workstation.

One question… should I expect any weird interactions with the ASRockRack OpenBMC when running EDK2 firmware?

I don’t think there’s anything like that, but it’s possible I’ve missed it.

Trying to build it reminded me how I dislike EDK2 being written by MS Windows programmers…

make: Leaving directory '/home/marcin/devel/linaro/sbsa-qemu/code/edk2/BaseTools'
+ . /home/marcin/devel/linaro/sbsa-qemu/code/edk2-platforms/Platform/Ampere/Tools/fw_ver.sh UPDATE
++ touch $'.fw_bld\r'
+++ cat .fw_bld
cat: .fw_bld: No such file or directory
++ BUILD=$'\r'

\r everywhere…

A few dos2unix calls later it built.

Now will hunt for TF-A binaries.

EDIT:
ALTRAD8UD-1L2T 2.06 firmware is 32MB file. EDK2 binary is 10MB file.

Now, which parts of 2.06 firmware I should take as SCP and TF-A?

Or should I follow edk2-ampere-tools/README.md and write to developer@amperecomputing.com instead?

Or should I follow edk2-ampere-tools/README.md and write to developer@amperecomputing.com instead?

I tried emailing them in early 2023 and got no reply.

Now, which parts of 2.06 firmware I should take as SCP and TF-A?

Try searching for ‘layout’ in the git log of edk2-ampere-tools.

1 Like

OK

    The new SPI-NOR layout:
    SPI-NOR Absolute ADDRESS  Size  Description
    0x000.0000  0x0007.FFFF 512 KB  UEFI ENV
    0x008.0000  0x000F.FFFF 512 KB  UEFI ENV (backup)
    0x010.0000  0x0010.FFFF  64 KB  NV-parameter (backup)
    0x011.0000  0x0011.FFFF  64 KB  NV-parameter
    0x012.0000  0x0012.FFFF  64 KB  Failsafe status
    0x013.0000  0x0015.FFFF 192 KB  BERT / Crash dump
    0x016.0000  0x001E.FFFF 512 KB  DDR parameters
    0x01F.0000  0x002E.FFFF   1 MB  Secure variable
    0x02F.0000  0x003E.FFFF   1 MB  Custom MM SP
    0x03F.0000  0x003F.FFFF  64 KB  Reserved
    0x040.0000  0x004F.FFFF   1 MB  ATF BL1, BL2, BL31, BL32
    0x050.0000  0x005E.FFFF 960 KB  ATF reserved
    0x05F.0000  0x005F.FFFF  64 KB  Board Settings
    0x060.0000  0x01FF.FFFF  26 MB  UEFI

0x400000 is 1MB part with TF-A.

The other part required by the buildfw.sh script is SCP. Which is used by the other script (edk2-build.sh in edk2-ampere-tools).

I suspect that it is 0x5F0000 part called ‘Board Settings’ as space for SCP is 256KB.

For the ASRock ALTRA8UD8-1L2T, the 10 MB EDK2 UEFI image without TF-A goes at address 0x600000 in the EEPROM. I used dd to write it into a stock bios update image (which is a 32 MB image with the TF-A at 0x400000 and the AMI UEFI starts at 0x600000 with what is probably a signing certificate followed by a UEFI firmware volume), in my case I used the 3.06 beta image from ASRock. I run the 3.06 beta OpenBMC and was on the ASRock stock 3.06 beta UEFI.

eg, dd if=edk2-uefi.bin of=stock-bios.bin bs=1MB seek=6 conv=notrunc

I copied the now-customized 32 MB EEPROM image to /tmp in the BMC, and ran ampere_flash_bios.sh on the BMC. By default the script only copies the passed image starting at 0x400000 to EEPROM, leaving the variable storage, etc from 0x0-0x3fffff untouched.

ADDENDUM: You would get the same result functional result starting with a zero’d 32 MB image, copying the stock firmware segment from 0x400000-0x5fffff (TF-A stuff), and putting the EDK2 image starting at 0x600000.

2 Likes

I should also note that in my testing, I found editing Altra1L2T.dsc to change the default video resolution to 800x600 instead of 0x0 (auto maximum) made video output on the splash screen and the UEFI Setup more consistent and useable between the AST (BMC KVM), the serial console, and my Nvidia RTX 3060.

And if you use Intel Arc graphics (tested with A380)
a) there is no UEFI video output even with the X86 firmware emulator enabled, and b) you have to enable Resizable BAR in EDK2, which is a one-line addition in the same .dsc file, added after some of the other Pcie Pcd settings

gEfiMdeModulePkgTokenSpaceGuid.PcdPcieResizableBarSupport|TRUE

Also, not sure if it is a race condition or a soft versus hard reset issue with the Nvidia 3060, but some boots I don’t get UEFI video output on the 3060. If I run “reconnect -r” in the UEFI shell, the 3060 will then start to output video. For now, my default boot entry is the shell, and my startup.nsh runs the reconnect, followed by my default boot loader.

2 Likes

Nope, the SCP code is stored in a separate EEPROM. On the BMC, the /usr/sbin/ampere_firmware_upgrade.sh script updates it, using the ampere_eeprom_prog.sh helper.

1 Like

Hmm, shell scripts are exempt from the DOS line ending rules, and I just checked and fw_ver.sh doesn’t have any CRs - only LFs.

1 Like

Hi,

Do you have some guidance to build the firmware from the begining for a ALTRAD8UD-1L2T ?

I end with

error 000E: File/directory not found in workspace
Platform/Ampere/JadePkg/root.cer.gEfiSecurityPkgTokenSpaceGuid.PcdPkcs7CertBuffer.inc is not found in packages path:

@bdherouville That file should have been created by the build script, by running Platform/Ampere/Tools/GenerateSecureBootKeys.sh.

Could you share the full build output please? If you’re not aware of it, you can use the script command - e.g. script -c "buildfw.sh -m ASRockRack -p Altra1L2T -b RELEASE" buildoutput.txt