Hi!
I have previously expressed my interest on GSoC. During the summer 2013, I would like to attack some of the early debugging problems I have seen people often come across when starting a port of a new mainboard for coreboot.
My proposal includes ideas taken from "coreboot panic room" and "SerialICE" project ideas, as well as early cbmem. I have identified some old patches that should go upstream first, so there would be a combination of new development, maintenance, as well as integration of some new features to older boards.
This is not a sorted list by effort estimation or importance, just some topics I could work on to improve the debugging environment one has to cope with when porting for a new mainboard.
1.
User of SerialICE usually has the goal to port a board to coreboot. By building serialice.rom as a romstage instead of separate flash image, one can re-use the coreboot tree structure and the early superio setup sources. First step of any new port would then be to commit a mainboard directory with SerialICE and console debugging capabilities.
2.
SerialICE with EHCI debug is currently a quick hack for one board. Integrate it properly for all boards. Motivation for this is that serial ports are not always available and also my DIY EHCI debug dongle could use more testing.
3.
SerialICE has the capability to capture any PCI/IO/MEM accesses during the early boot stages from the target-host communication link, while running vendor bios in QEmu.
Implement similar sniffer functionality when coreboot goes through ramstage and log all the accesses in cbmem. While this would not help raminit problems, it could help solve problems where PCI subsystem has incorrect initialization sequences. I found it hard to understand how walking the devicetree really works reading the source alone as Agesa wrappers are pretty difficult to master.
4.
SerialICE communication could use a more efficient protocol, especially with the 8 byte packet length restriction of EHCI debug. Could one multiplex coreboot console and SerialICE and GDB in some fashion here?
5.
One of the main tasks I would like to accomplish is to be able to reprogram flash even when some stage of boot process has prevented from entering OS. I do not have the latest status of FILO developments or Flashrom as payload, I believe there is some working code for some selected hardware already.
It appears the GSoC 2011 project of panic room and running flashrom in cache-as-ram environment did not produce a suitable generic solution for upstream. Should this be investigated further?
6.
What is the status of debug console support in different payloads? I quess superio based UARTs in IO space are the only ones generally supported, while MMIO UARTs and EHCI debug ports may have existing patches out there somewhere?
For now, I would much appreciate comments if some of the topics above are just "bad idea, don't", and/or if some ideas are already implemented but not merged upstream, and/or if you have active development that would void my work or vice-versa.
Regards, Kyösti