# Google Summer of Code

The SerialICE project participated in GSoC under the patronage of
[coreboot's GSoC administration][coreboot GSoC].

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.

## 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](http://rada.re/y/?p=features)
- 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.

## 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](http://www.unicorn-engine.org/) 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)

[coreboot GSoC]: https://doc.coreboot.org/contributing/gsoc.html