Documentation: Add broader payload coverage to project ideas

A couple people discussed recently how it's a shame that on some
architectures we can bring up a device but then have nothing to do with
it afterwards. Having payloads to choose from would help a lot there.

Change-Id: Ia66f22947d09afe3076cc2ee12f5b652fe80fc3a
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/31415
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>

1 files changed, 19 insertions, 0 deletions

diff --git a/Documentation/contributing/project_ideas.md b/Documentation/contributing/project_ideas.md
index 1c23cc6bc7b8..2e43871149e2 100644
--- a/Documentation/contributing/project_ideas.md
+++ b/Documentation/contributing/project_ideas.md
@@ -91,3 +91,22 @@ would help to ensure code quality and make the runtime code more robust.
 
 ### Mentors
 * Werner Zeh <werner.zeh@gmx.net>
+
+## Port payloads to ARM, AArch64, MIPS or RISC-V
+While we have a rather big set of payloads for x86 based platforms, all other
+architectures are rather limited. Improve the situation by porting a payload
+to one of the platforms, for example GRUB2, U-Boot (the UI part), Tianocore,
+yabits, FILO, or Linux-as-Payload.
+
+Since this is a bit of a catch-all idea, an application to GSoC should pick a
+combination of payload and architecture to support.
+
+### Requirements
+* coreboot knowledge: Should know the general boot flow in coreboot
+* other knowledge: It helps to be familiar with the architecture you want to
+  work on.
+* hardware requirements: Much of this can be done in QEMU or other emulators,
+  but the ability to test on real hardware is a plus.
+
+### Mentors
+* Simon Glass <sjg@chromium.org> for U-Boot payload projects