describe strategies to fit LinuxBoot into boot chains

Nobody has claimed this yet.

## coreboot and oreboot

### Tools

Use the existing build system.
These projects already support providing a LinuxBoot image as a payload.

### Strategy

With coreboot, it is a Kconfig option. Already in use (by who?).

With oreboot, pass an argument to the build system.

### Open issues

Building the kernel etc through coreboot's build system may be intimidating and harder to grasp than building the payload independently and including it as a binary. More documentation needed for full automation.

In the case of oreboot, the LinuxBoot image must be built by the user.
We could eventually provide prebuilt ones per platform.

## U-Boot

### Tools

The U-Boot build system is already there.

### Strategy

Rework the U-Boot build setup so that any FIT image can be provided as a payload in place of U-Boot Proper, similar to coreboot.

Allow passing an env var, just like when inserting a TF-A image.

### Open issues

Keep the framework from building U-Boot proper when it's not needed.

## UEFI PI

Basically retrofitting onto TianoCore and its derivatives.
This one is the trickiest, since it starts from binaries, not sources.

### Tools

- [Fiano](https://github.com/linuxboot/fiano/) `utk` + `dxecleaner`/`tightenme` visitors
- [Fiedka](https://fiedka.app/)
- `me_cleaner` / [`intel_fw`](https://github.com/platform-system-interface/intel_fw)

### Strategy

Remove as many UEFI modules as necessary to gain enough space for the LinuxBoot image. Start with educated guessing and a "good enough" result.

With Fiedka, save the list of removals for sharing in a repo.
Create a simple CLI for replay, so that it can be automated.

With `utk` as a CLI, save the commands in a `Makefile` (as in [linuxboot/mainboards/aeeon/up](https://github.com/linuxboot/linuxboot/blob/main/mainboards/aeeon/up/Makefile)) or save the list of removals in a text file (needs better tooling; Heads had developed [Perl scripts](https://github.com/linuxboot/linuxboot/blob/main/lib/EFI.pm) and `awk` snippets, see e.g. [linuxboot/boards/monolake](https://github.com/linuxboot/linuxboot/blob/main/boards/monolake/Makefile.board) and [linuxboot/Makefile](https://github.com/linuxboot/linuxboot/blob/main/Makefile)).
Maybe align with Fiedka, save the removals in a JSON file and add a replay command/visitor or similar to Fiano/`utk`.

Possibly rework partitioning in order to gain more space; for Intel platforms, see `utk`'s `tightenme` visitor or `intel_fw`/`me_cleaner` to remove unnecessary parts of the (CS)ME (e.g., consumers need no AMT).

Add a `README.md` with general instructions and further necessary operations. Explain the hardware setup and caveats.

### Open issues

Tooling for AMD platforms still needs improvement; see [Romulan](https://github.com/fiedka/romulan) and (planned) [`amd_fw`](https://github.com/platform-system-interface/amd_fw).
How about UEFI PI on aarch64? Which vendors implement it?

For automated removal (`dxecleaner`) of as much as possible, a hardware tool such as 3mdeb RTE is necessary in order to reflash, reset, and monitor the result. It may take a lot of hours.

Start by reading the linked linuxboot Makefiles, including mainboards/aeeon/up/Makefile, boards/monolake/Makefile.board, Makefile, and lib/EFI.pm, then compare the coreboot, oreboot, U-Boot, and UEFI PI strategies described here. A completed effort would provide README.md guidance, explain hardware setup and caveats, and document or automate the relevant payload-building and firmware-module-removal workflows.

Written by the indexing model from the issue text.