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>
This commit is contained in:
Patrick Georgi 2019-02-14 13:24:44 +01:00
parent 358cbb3a30
commit 3ce88e1fa0
1 changed files with 19 additions and 0 deletions

View File

@ -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