Hi Bin, On 14 August 2015 at 15:15, Bin Meng <bmeng...@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 >> 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. [...] > 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. -- igor _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
