[U-Boot] [PATCH v4 1/5] x86: Add a target for running as a coreboot payload

[Gabe Black]

On Thu, Nov 17, 2011 at 2:26 AM, Graeme Russ <graeme.russ at gmail.com> wrote:

> Hi Gabe,
>
> On 17/11/11 21:11, Gabe Black wrote:
> >
> >
> > On Thu, Nov 17, 2011 at 1:43 AM, Graeme Russ <graeme.russ at gmail.com
> > <mailto:graeme.russ at gmail.com>> wrote:
> >
> >     Hi Gabe,
> >
> >     On 17/11/11 11:27, Gabe Black wrote:
> >     > Add a target for running u-boot as a coreboot payload in
> boards.cfg.
> >     >
> >     > Signed-off-by: Gabe Black <gabeblack at chromium.org
>
> [snip]
>
> >
> >     As mentioned by others before, there is no reason to have these as
> discrete
> >     patches - Please merge into a single 'Add coreboot payload'
> >
> >
> >
> > Ok. Since there are more patches here than I sent out previously and one
> > big patch seemed like it was more than "exactly one complete logical
> > change" I wanted to find out how these should be merged. If they should
> all
> > be merged, then that answers the question.
>
> Well, if a given patch is meaningless without another, they really should
> be combined. Of course there are exceptions, like adding a new driver - The
> code for it gets added in one patch, and the usage in a board in another
>
> >     Is there any real reason to reference 'chromebook-x86'?
> >
> > I don't follow. I'm not referencing it, that's what we're calling our
> board
> > since it's an x86 chromebook.
>
> I mean, if this is 'generic', why is there a reference to the chromebook?
>


The way it's ended up, the coreboot "CPU" is generic to coreboot, the
"board" is generic to chromebooks, and the config is either generic to
chromebooks or, if we decide we need it to be, specialized per specific
chromebook.



>
> >     And finally, what is the plan for motherboard specific coreboot
> variants?
> >
> >
> >
> > We haven't worked out all the details, but our current working plan is
> that
> > coreboot itself will be specialized per board and that U-Boot will stay
> > fairly generic and be specialized as needed using the device tree. We may
> > find that a single version of U-Boot with a superset of drivers is too
> big
> > and we need to have different configs for each variant.
>
> This probably won't work in and of itself without a major overhaul of the
> U-Boot driver architecture :)
>
> Boards will need their own config for Ethernet drivers for example
>


This is working just fine so far, actually. It may not scale and we won't
be able to have more than one kind of certain things, but in the mean time
it's working for us. We are aware of these potential/eventual problems
though.

Gabe