Re: [U-Boot] [PATCH v4 1/5] x86: Add a target for running as a coreboot payload
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 gabebl...@chromium.org --- Changes in v2: Change capitalization of the x86 tag. Changes in v3: Move the Signed-off-by line up. Changes in v4: Change the summary tag style. boards.cfg |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/boards.cfg b/boards.cfg index 8b7a03b..4b2a1a7 100644 --- a/boards.cfg +++ b/boards.cfg @@ -272,6 +272,7 @@ tcm-bf518blackfinblackfin tcm-bf537blackfinblackfin eNET x86 x86eNET- sc520 eNET:SYS_TEXT_BASE=0x3804 eNET_SRAMx86 x86eNET- sc520 eNET:SYS_TEXT_BASE=0x1900 +coreboot-x86 x86 x86coreboot chromebook-x86 corebootcoreboot:SYS_TEXT_BASE=0xFC sandbox sandbox sandbox sandbox sandbox- cobra5272m68kmcf52x2 cobra5272 - idmr m68kmcf52x2 As mentioned by others before, there is no reason to have these as discrete patches - Please merge into a single 'Add coreboot payload' Is there any real reason to reference 'chromebook-x86'? And finally, what is the plan for motherboard specific coreboot variants? Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 1/5] x86: Add a target for running as a coreboot payload
On Thu, Nov 17, 2011 at 1:43 AM, Graeme Russ graeme.r...@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 gabebl...@chromium.org --- Changes in v2: Change capitalization of the x86 tag. Changes in v3: Move the Signed-off-by line up. Changes in v4: Change the summary tag style. boards.cfg |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/boards.cfg b/boards.cfg index 8b7a03b..4b2a1a7 100644 --- a/boards.cfg +++ b/boards.cfg @@ -272,6 +272,7 @@ tcm-bf518blackfinblackfin tcm-bf537blackfinblackfin eNET x86 x86eNET - sc520 eNET:SYS_TEXT_BASE=0x3804 eNET_SRAMx86 x86eNET - sc520 eNET:SYS_TEXT_BASE=0x1900 +coreboot-x86 x86 x86coreboot chromebook-x86 corebootcoreboot:SYS_TEXT_BASE=0xFC sandbox sandbox sandbox sandbox sandbox- cobra5272m68kmcf52x2 cobra5272 - idmr m68kmcf52x2 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. 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. 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. Gabe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 1/5] x86: Add a target for running as a coreboot payload
Hi Gabe, On 17/11/11 21:11, Gabe Black wrote: On Thu, Nov 17, 2011 at 1:43 AM, Graeme Russ graeme.r...@gmail.com mailto:graeme.r...@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 gabebl...@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? 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 Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 1/5] x86: Add a target for running as a coreboot payload
On 11/17/11, Graeme Russ graeme.r...@gmail.com wrote: Hi Gabe, [snip] 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? I think a name like coreboot-x86 could make sense here, but it shouldn't have dependence on drivers specific for chromebook hardware. Only 'generic' drivers as vesa video and keyboard input needs to be referenced on it. Then others developers could extend it to their specific hardware, adding items like ethernet, mmc/sd driver, etc Best Regards, Alan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 1/5] x86: Add a target for running as a coreboot payload
On Thu, Nov 17, 2011 at 2:26 AM, Graeme Russ graeme.r...@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.r...@gmail.com mailto:graeme.r...@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 gabebl...@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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
