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:
parent
358cbb3a30
commit
3ce88e1fa0
|
@ -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
|
||||
|
|
Loading…
Reference in New Issue