+Simon
Hi Igor,
On Fri, Aug 14, 2015 at 8:33 PM, Stoppa, Igor igor.stoppa@intel.com wrote:
Hi Bin,
On 14 August 2015 at 15:15, Bin Meng bmeng.cn@gmail.com wrote:
These are Kconfig options. I am not sure what makes you think they are binary?
Binary as commented out vs set to y
I guess you mean boolean? Binary makes me think some image file ..
That might be inferred from the doc, when it is said to set a certain option. So one might just try to set it to "y" But it's not 100% obvious.
Again, these are Kconfig stuff. You can easily add these options by looking at the existing options in the same config file, even without knowing Kconfig.
But some Kconfig options are used as strings, so one could be set as:
CONFIG_SOME_OPTION="something"
and another could be unset as:
CONFIG_SOME_OTHER_OPTION=""
That's what I meant.
OK, all of these are boolean. You can double check the Kconfig files.
[...]
I believe the intention here is that we don't want to create too many board defconfig files with just one or two different option(s). With EFI payload, technically almost every x86 board we support can support building as the EFI payload. If we do that way, we may end up creating too many config variants to "pollute" the U-Boot source tree. The defconfig files (as indicated by its name) is only the default configuration for a board and one can adjust the file with whatever options he likes to add/remove.
Yes, I understand.
In the end it's a decision on the trade-off between having a terse directory and file layout vs. giving 1st time users something that works out of the box.
As 1st time user I would obviously go for the latter :-) If there is something that _is_ expected to work, it reduces the problem space I have to debug when I experience a failure.
--
Regards, Bin