Your branch is ahead of origin/master by 48 commits.
Yes, I knew this would happen, it has become increasingly difficult to push new work for review on gerrit, as I have dependencies on existing work waiting for merge. As the pile of un-merged patches increases so does the time I spend with git rebase, so I am hoping for some progress on that side.
My eyes in the local working directory have turned towards SerialICE integration inside coreboot tree. The benefits of this approach are better tree structure, wider hardware support, cache-as-ram and usbdebug.
There are several use-cases to consider:
- Compile classic stand-alone SerialICE ROM image with ROMCC, using super-IO and chipset initialisation from coreboot tree.
- Compile SerialICE as an alternative romstage with ROMCC, using existing coreboot bootblock added with serial port initialisation.
- Compile SerialICE as romstage with GCC and cache-as-ram to use existing usbdebug code and possibly better execution performance.
- Add abilility to jump out of SerialICE to regular romstage.
Also for the SerialICE session on debug host we have alternatives:
- Execute vendor BIOS image under QEMU.
- Execute coreboot image under QEMU.
- Execute coreboot image in user-mode under GDB without QEMU.
- Execute utils like nvramtool, msrtool, inteltool, superiotool, lspci and setpci remotely.
Now all of the above has been demonstrated before but not adopted. Adopting these widely for all mainboards may not happen during my GSoC, as there is no common function to call to enable a serial-port from romstage. At the minimum I will make some simple example one can follow to get SerialICE running on boards with existing coreboot support.