On Thu, Nov 17, 2011 at 2:26 AM, Graeme Russ graeme.russ@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@gmail.com mailto:graeme.russ@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 inboards.cfg.
> > Signed-off-by: Gabe Black <gabeblack@chromium.org[snip]
As mentioned by others before, there is no reason to have these asdiscrete
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 corebootvariants?
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