GSoC

The SerialICE project will hopefully participate in GSoC 2016 under the patronage of coreboot's GSoC administration. Depending on the number and quality of applications, and available mentors, there might be room for a separate SerialICE project. If you're interested, please send your thoughts and ideas on the mailing list and come discuss them on IRC irc://irc.freenode.net/#coreboot.

It is not likely that the project organisation would supply any hardware required to complete or even start a project on SerialICE. So if you want to apply, you should first try building and running SerialICE yourself to understand its current capabilities and weaknesses. You really don't need a high-end mainboard or CPUs on these projects. While it's a powerful tool for low-level debugging and understanding even part of it requires a fair amount of knowledge on x86 architecture, there are also challenges in the user interface development.

The list below is a collection of improvement ideas and capabilities that would be nice to have. Some of these could be merged with coreboot GSoC projects or support flashrom GSoC projects.

SerialICE on target

• Build target ROM image with super-IO and PnP from coreboot tree.
• Support EHCI debug port, extend the protocol for memory block moves.
• Investigate possibilities to catch SMI and run System Management Mode.

SIMBA, the filtering subsystem

• Query PCI IDs to detect chipsets and load filters automatically.
• Enable modifying SMBus traffic on-the-fly to forge SPD data for testing purposes.
• Create log output conditionally of CS:EIP or accessed PCI device.
• Decode PCI/PCI-e standard configuration registers.
• Enable injection of IO and memory transactions.

User interface

• Well, provide one. Now it is just a logfile and a script.
• Display SerialICE log in parallel with disassembly. Could be integrated with radare2
• Visualize PCI devicetree configuration sequence and allocations.
• An editor that knows the log format and supports user-assisted folding of loops that wait for bit flips, naming of registers, ...
• Integration with GDB and DDD.

coreboot

• Collect IO and PCI transactions on boot and store them in cbmem. Replay them to see what devicetree really did during ramstage.
• Complete and merge coreboot panic room results upstream.

QEMU

• Update to a more current QEMU.
• Support other architectures.
• Create hybrid platform, where some devices are emulated and some run on real hardware.

Port to Unicorn

Unicorn may be a more suitable (and maybe even stable) base for our purposes than QEmu because it shares some of SerialICE's goals. Needs investigation if that's actually a good idea _before_ GSoC starts (although such an investigation is already a great way to show that you're capable of finishing this project)