[RFC] Improving early debugging as GSoC project - coreboot

17 Apr 2013


      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