to an ARM system. Unfortunately I am missing the big picture. I just see<br>
patches getting pushed to Gerrit and most of them getting approved.<br></blockquote><div><br></div><div>We've been a bit liberal with pushing commits and less-than-perfect patches simply because we're doing something new and mostly in parallel with x86 development. If anyone else is actively porting Coreboot to an ARM platform, please let us know! We'd love to get more people involved and coordinating with us.</div>

<div><br></div><div>Our first ARM-based target is, naturally, the Samsung Chromebook (XE303C12, which we call "snow"). If you're interested in getting involved, I recommend the <a href="http://www.arndaleboard.org/wiki/index.php/Main_Page" target="_blank">Arndaleboard</a> development kit ($249US, available now) which uses the same Exynos5250 processor and can leverage much of the work we're doing now.</div>

<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">This is probably the result of upstreaming work early on so that trees<br>

do not diverge. Which is great!</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> My impression is that only you<br>

Google developers know what you are doing and can review the patches.<br></blockquote><div><br></div><div>We are trying to be as public as we can. As you point out, one of the greatest advantages is that this helps keep our trees and patches up to date and avoid diverging. But we're also trying to move fast on this so that there is a working model in place. This is particularly true for very early code where a lot of tribal knowledge about the hardware is required to make anything work at all.</div>

<div><br></div><div>Now that we're booting into romstage and have debug messages coming out of a serial console, it will be much easier to parallelize development tasks and test proposed changes. Please feel free to comment on patches that have already been committed, or send patches to fix things you think should be done differently.</div>

<br>
And a nice understandable commit history and overview would make life<br>
for possible PowerPC (or other architectures) porters easier. Though<br>
that is just another guess from my side.<br></blockquote><div><br></div><div>We certainly intend to document and present our work, and hopefully that will be helpful to those wanting to do a new port. A clean commit history would certainly be nice though I don't think it's realistic. Nobody actively involved in this particular port has perfect knowledge about how this will look in the end. We've learned a lot on the way, tossed out some patches and re-visited older decisions. We iterate and improve, sharing our code as we go.</div>

<div><br></div><div>As Ron points out, the monstrous bootblock we have right now is a good example. For a long time we were literally using the power LED as our only means of debugging this particular board (JTAG is usually difficult on production hardware). We needed something to give us useful debug info out of the serial port, which for this platform entails doing a lot of other work to configure power rails, pin muxes and clocks. Now that we've gotten further along we can clean up the bootblock and move a lot of things to romstage where they belong.</div>

<div><br></div><div>It would've been the same had we developed everything internally and then sent a sanitized patchset upstream ex post facto, only without the instructive (perhaps cautionary) early debugging parts. Thankfully this is the coreboot mailing list, where ugly early debugging is a way of life :-)</div>