Big picture of recent ARM patches?

[Paul Menzel]

Dear coreboot folks,

it is great to see the past and current development of coreboot. Even
better that hardware/devices with coreboot installed can be bought.
Thank you for making that possible.

Google’s coreboot developers latest effort seems to be to port coreboot
to an ARM system. Unfortunately I am missing the big picture. I just see
patches getting pushed to Gerrit and most of them getting approved.

This is probably the result of upstreaming work early on so that trees
do not diverge. Which is great!

So it would be awesome if there would be a public roadmap, so that at
least myself can get a small overview. My impression is that only you
Google developers know what you are doing and can review the patches.
But that might miss valuable comments from the other core coreboot
developers regarding certain design decisions.

And a nice understandable commit history and overview would make life
for possible PowerPC (or other architectures) porters easier. Though
that is just another guess from my side.

Thanks,

Paul

[ron minnich]

I'm delighted that you are interested!

This is our first multi-arch port in 10 years. The platform we are
porting to is not without its difficulties:
- rom is not memory addressed
- we don't own the first two stages of firmware, they are binary blobs
and one of them is in the mask rom
  but we have to deal with it, this is how things are going to be on
most CPUs in coming years.
- we don't have a convenient serial port
- no really good jtag path

This is one of the harder platforms we've worked with.

The guiding principle is to make the ARM port match how we do things
in coreboot today:bootblock, romstage, ramstage. But to get here we
have to pollute things a bit at first. You see this in the serial port
in the bootblock, which we hope to remove sometime next week.

I like committing these intermediate targets. This is a good case
study of how to do a part, which you can refer to in coming years for
new ports. I'd be even happier if we got you folks interested in
taking a look at the code too. Just be aware that some of this is
pretty kludgy, and will change, but I really want people to see the
ugly parts of a port. Just showing a final version would not be as
instructive.

I doubt we've got time to do a full roadmap, but I have time to answer
questions :-)

And maybe you can take your -1 off my firmware CL :-)

ron

[David Hendricks]

On Fri, Jan 18, 2013 at 8:15 AM, Paul Menzel <
[e-mail]> wrote:
> Google’s coreboot developers latest effort seems to be to port coreboot
> to an ARM system. Unfortunately I am missing the big picture. I just see
> patches getting pushed to Gerrit and most of them getting approved.

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.

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 Arndaleboardhttp://www.arndaleboard.org/wiki/index.php/Main_Page
development
kit ($249US, available now) which uses the same Exynos5250 processor and
can leverage much of the work we're doing now.

This is probably the result of upstreaming work early on so that trees
> do not diverge. Which is great!

My impression is that only you
> Google developers know what you are doing and can review the patches.

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.

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.

But that might miss valuable comments from the other core coreboot
> developers regarding certain design decisions.
> And a nice understandable commit history and overview would make life
> for possible PowerPC (or other architectures) porters easier. Though
> that is just another guess from my side.

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.

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.

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 :-)