Patrick Georgi has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/31415
Change subject: Documentation: Add broader payload coverage to project ideas ......................................................................
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 --- M Documentation/contributing/project_ideas.md 1 file changed, 18 insertions(+), 0 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/15/31415/1
diff --git a/Documentation/contributing/project_ideas.md b/Documentation/contributing/project_ideas.md index 0a39a88..7bcf2c7 100644 --- a/Documentation/contributing/project_ideas.md +++ b/Documentation/contributing/project_ideas.md @@ -72,3 +72,21 @@ hardware is available.
### Mentors + +## 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 konw 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