[U-Boot] efi: Error building as EFI payload (both 32bit and 64 bit)
Hello, I'm using the HEAD of the master branch from git://git.denx.de/u-boot-x86.git I want to build U-Boot as 64bit EFI payload.
According to docs/README.efi, I've done the following:
u-boot-x86> make qemu-x86_defconfig u-boot-x86> make menuconfig
x86 architecture ---> Mainboard vendor ---> efi x86 architecture ---> Mainboard model ---> efi Library routines ---> [*] Support running U-Boot from EFI Library routines ---> Select EFI mode to use ---> Support running as an EFI payload Library routines ---> EFI 32/64-bit selection ---> Produce a stub for running with 64-bit EFI
Save as .config and Exit
u-boot-x86> make
Here it builds for a while, but eventually fails when reaching:
CC lib/efi/efi_stub.o lib/efi/efi_stub.c: In function ‘get_codeseg32’: lib/efi/efi_stub.c:188:30: error: ‘CONFIG_SYS_MONITOR_LEN’ undeclared (first use in this function) CONFIG_SYS_TEXT_BASE + CONFIG_SYS_MONITOR_LEN < limit ^ lib/efi/efi_stub.c:188:30: note: each undeclared identifier is reported only once for each function it appears in scripts/Makefile.build:277: recipe for target 'lib/efi/efi_stub.o' failed make[2]: *** [lib/efi/efi_stub.o] Error 1 scripts/Makefile.build:422: recipe for target 'lib/efi' failed make[1]: *** [lib/efi] Error 2 Makefile:1206: recipe for target 'lib' failed make: *** [lib] Error 2
I tried also with the 32bit stub and I get a different (linker) error: arch/x86/cpu/start.o: In function `_start': /home/igor/dev/tmp/bbb/u-boot-x86/arch/x86/cpu/start.S:87: undefined reference to `early_board_init' arch/x86/cpu/built-in.o: In function `pci_init_board': /home/igor/dev/tmp/bbb/u-boot-x86/arch/x86/cpu/pci.c:58: undefined reference to `board_pci_setup_hose' drivers/serial/built-in.o: In function `x86_serial_ofdata_to_platdata': /home/igor/dev/tmp/bbb/u-boot-x86/drivers/serial/serial_x86.c:25: undefined reference to `ns16550_serial_ofdata_to_platdata' drivers/serial/built-in.o:(.u_boot_list_2_driver_2_serial_ns16550+0x10): undefined reference to `ns16550_serial_probe' drivers/serial/built-in.o:(.u_boot_list_2_driver_2_serial_ns16550+0x3c): undefined reference to `ns16550_serial_ops' Makefile:1188: recipe for target 'u-boot' failed make: *** [u-boot] Error 1
Any idea of what mistakes I am making?
Hi Igor,
On Thu, Aug 13, 2015 at 8:11 PM, Stoppa, Igor igor.stoppa@intel.com wrote:
Hello, I'm using the HEAD of the master branch from git://git.denx.de/u-boot-x86.git I want to build U-Boot as 64bit EFI payload.
According to docs/README.efi, I've done the following:
u-boot-x86> make qemu-x86_defconfig u-boot-x86> make menuconfig
x86 architecture ---> Mainboard vendor ---> efi x86 architecture ---> Mainboard model ---> efi
These two should not be changed for EFI payload. What you selected is for EFI application.
Library routines ---> [*] Support running U-Boot from EFI Library routines ---> Select EFI mode to use ---> Support running as an EFI payload Library routines ---> EFI 32/64-bit selection ---> Produce a stub for running with 64-bit EFI
Save as .config and Exit
u-boot-x86> make
Here it builds for a while, but eventually fails when reaching:
CC lib/efi/efi_stub.o lib/efi/efi_stub.c: In function ‘get_codeseg32’: lib/efi/efi_stub.c:188:30: error: ‘CONFIG_SYS_MONITOR_LEN’ undeclared (first use in this function) CONFIG_SYS_TEXT_BASE + CONFIG_SYS_MONITOR_LEN < limit ^ lib/efi/efi_stub.c:188:30: note: each undeclared identifier is reported only once for each function it appears in scripts/Makefile.build:277: recipe for target 'lib/efi/efi_stub.o' failed make[2]: *** [lib/efi/efi_stub.o] Error 1 scripts/Makefile.build:422: recipe for target 'lib/efi' failed make[1]: *** [lib/efi] Error 2 Makefile:1206: recipe for target 'lib' failed make: *** [lib] Error 2
I tried also with the 32bit stub and I get a different (linker) error: arch/x86/cpu/start.o: In function `_start': /home/igor/dev/tmp/bbb/u-boot-x86/arch/x86/cpu/start.S:87: undefined reference to `early_board_init' arch/x86/cpu/built-in.o: In function `pci_init_board': /home/igor/dev/tmp/bbb/u-boot-x86/arch/x86/cpu/pci.c:58: undefined reference to `board_pci_setup_hose' drivers/serial/built-in.o: In function `x86_serial_ofdata_to_platdata': /home/igor/dev/tmp/bbb/u-boot-x86/drivers/serial/serial_x86.c:25: undefined reference to `ns16550_serial_ofdata_to_platdata' drivers/serial/built-in.o:(.u_boot_list_2_driver_2_serial_ns16550+0x10): undefined reference to `ns16550_serial_probe' drivers/serial/built-in.o:(.u_boot_list_2_driver_2_serial_ns16550+0x3c): undefined reference to `ns16550_serial_ops' Makefile:1188: recipe for target 'u-boot' failed make: *** [u-boot] Error 1
Any idea of what mistakes I am making?
Regards, Bin
Hi Bin,
On 13 August 2015 at 15:37, Bin Meng bmeng.cn@gmail.com wrote:
x86 architecture ---> Mainboard vendor ---> efi x86 architecture ---> Mainboard model ---> efi
These two should not be changed for EFI payload. What you selected is for EFI application.
Thanks a lot. Now it built. If you don't mind I'll send also for this a patch for making the doc more n00b friendly :-)
Hi Igor,
On Thu, Aug 13, 2015 at 8:46 PM, Stoppa, Igor igor.stoppa@intel.com wrote:
Hi Bin,
On 13 August 2015 at 15:37, Bin Meng bmeng.cn@gmail.com wrote:
x86 architecture ---> Mainboard vendor ---> efi x86 architecture ---> Mainboard model ---> efi
These two should not be changed for EFI payload. What you selected is for EFI application.
Thanks a lot. Now it built. If you don't mind I'll send also for this a patch for making the doc more n00b friendly :-)
OK, patches are welcome.
Regards, Bin
Hi Bin,
On 13 August 2015 at 15:46, Stoppa, Igor igor.stoppa@intel.com wrote: for EFI application.
Thanks a lot. Now it built.
It built, but I didn't get much further :-(
I'm running qemu 2.1.3 on OpenSUSE and it doesn't seem to start in EFI mode other than with a build of the Open Virtual Machine Firmware that I found googling [1]. With this I can reach an EFI shell.
I tried both the BIOS that qemu would load by default and the one that the Testing page of the qemu wiki [2] provides [3] but they get stuck at some point that doesn't generate any output.
Anyway, with the OVMF, I am able to see the EFI BIOS starting. I can list the block devices and also see the file containing U-Boot in payload format (u-boot-payload.efi) This is how I start qemu:
qemu-system-x86_64 -nographic -bios ../bios/OVMF.fd -hda fat:tmp/efi/
It tries to boot from any of the boot devices available, then it fails and drops me to the Shell.
At which point, following the README.efi, I launch the payload:
FS0:u-boot-payload.efi
I get a message: U-Boot EFI Payload
which seems to indicate that something is happening, but nothing else.
Almost immediately the screen blanks and I get the usual sequence of Boot Failed messages that show which boot devices the BIOS tried.
Shouldn't I get the same interactive prompt that I see when using non-EFI mode?
[1] http://ufpr.dl.sourceforge.net/project/edk2/OVMF/OVMF-X64-r15214.zip [2] http://wiki.qemu.org/Testing [3] http://wiki.qemu.org/download/efi-bios.tar.bz2
+Simon
Hello Bin, Simon,
On 13 August 2015 at 17:52, Stoppa, Igor igor.stoppa@intel.com wrote:
I'm running qemu 2.1.3 on OpenSUSE and it doesn't seem to start in EFI mode other than with a build of the Open Virtual Machine Firmware that I found googling [1]. With this I can reach an EFI shell.
Almost the same also with qemu 2.2.0 on Ubuntu
[...]
Anyway, with the OVMF, I am able to see the EFI BIOS starting. I can list the block devices and also see the file containing U-Boot in payload format (u-boot-payload.efi) This is how I start qemu:
qemu-system-x86_64 -nographic -bios ../bios/OVMF.fd -hda fat:tmp/efi/
It tries to boot from any of the boot devices available, then it fails and drops me to the Shell.
At which point, following the README.efi, I launch the payload:
FS0:u-boot-payload.efi
I get a message: U-Boot EFI Payload
I have added some traces to the code. It seems that the failure happens at lib/efi/efi_stub.c:333 where it tries to get a memory map for the 2nd time.
[...]
Tomorrow I'll try again, after downloading and trying the latest qemu.
What version of qemu is known to work with the EFI x86 payload?
[1] http://ufpr.dl.sourceforge.net/project/edk2/OVMF/OVMF-X64-r15214.zip
Hi Igor,
On 13 August 2015 at 12:38, Stoppa, Igor igor.stoppa@intel.com wrote:
+Simon
Hello Bin, Simon,
On 13 August 2015 at 17:52, Stoppa, Igor igor.stoppa@intel.com wrote:
I'm running qemu 2.1.3 on OpenSUSE and it doesn't seem to start in EFI mode other than with a build of the Open Virtual Machine Firmware that I found googling [1]. With this I can reach an EFI shell.
Almost the same also with qemu 2.2.0 on Ubuntu
[...]
Anyway, with the OVMF, I am able to see the EFI BIOS starting. I can list the block devices and also see the file containing U-Boot in payload format (u-boot-payload.efi) This is how I start qemu:
qemu-system-x86_64 -nographic -bios ../bios/OVMF.fd -hda fat:tmp/efi/
It tries to boot from any of the boot devices available, then it fails and drops me to the Shell.
At which point, following the README.efi, I launch the payload:
FS0:u-boot-payload.efi
I get a message: U-Boot EFI Payload
I have added some traces to the code. It seems that the failure happens at lib/efi/efi_stub.c:333 where it tries to get a memory map for the 2nd time.
[...]
Tomorrow I'll try again, after downloading and trying the latest qemu.
What version of qemu is known to work with the EFI x86 payload?
I'm using 2.3.90.
Although there may be a dependency on EFI also. I found that the binary I downloaded, plus the two I built, worked OK.
[1] http://ufpr.dl.sourceforge.net/project/edk2/OVMF/OVMF-X64-r15214.zip
-- thanks, igor
Regards, Simon
Hi Igor,
On Fri, Aug 14, 2015 at 2:38 AM, Stoppa, Igor igor.stoppa@intel.com wrote:
+Simon
Hello Bin, Simon,
On 13 August 2015 at 17:52, Stoppa, Igor igor.stoppa@intel.com wrote:
I'm running qemu 2.1.3 on OpenSUSE and it doesn't seem to start in EFI mode other than with a build of the Open Virtual Machine Firmware that I found googling [1]. With this I can reach an EFI shell.
Almost the same also with qemu 2.2.0 on Ubuntu
[...]
Anyway, with the OVMF, I am able to see the EFI BIOS starting. I can list the block devices and also see the file containing U-Boot in payload format (u-boot-payload.efi) This is how I start qemu:
qemu-system-x86_64 -nographic -bios ../bios/OVMF.fd -hda fat:tmp/efi/
It tries to boot from any of the boot devices available, then it fails and drops me to the Shell.
At which point, following the README.efi, I launch the payload:
FS0:u-boot-payload.efi
I get a message: U-Boot EFI Payload
I have added some traces to the code. It seems that the failure happens at lib/efi/efi_stub.c:333 where it tries to get a memory map for the 2nd time.
[...]
Tomorrow I'll try again, after downloading and trying the latest qemu.
What version of qemu is known to work with the EFI x86 payload?
I am using QEMU 2.3.0 (built from source) and EFI BIOS (IA32 and X64, built from git source)
Regards, Bin
Hi Bin, Simon, thanks for your time, unfortunately I'm still having issues, please see below.
On 14 August 2015 at 05:09, Bin Meng bmeng.cn@gmail.com wrote:
I am using QEMU 2.3.0 (built from source) and EFI BIOS (IA32 and X64, built from git source)
I downloaded and built the latest stable QEMU: 2.4.50 according to https://en.wikibooks.org/wiki/QEMU/Linux
And I got the binary EFI firmware from the Tianocore website (http://www.tianocore.org/ovmf/)
------
Both 32 bit and 64 bit payloads still fail, however not in the same way:
32 bit:
I run qemu-system-i386 --nographic --bios ../OVMF-IA32/OVMF.fd -hda fat:payload32/efi/
Shell> u-boot-payload.efi U-Boot EFI Payload !!!! IA32 Exception Type - 00000006 CPU Apic ID - 00000000 !!!! EIP - FFF00012, CS - 00000010, EFLAGS - 00000046 EAX - 00000000, ECX - 067FA010, EDX - 00000000, EBX - 066EE000 ESP - 07FAFAC0, EBP - 066EE000, ESI - FFF00000, EDI - 07FC0FC8 DS - 00000008, ES - 00000008, FS - 00000008, GS - 00000008, SS - 00000008 CR0 - 40000033, CR2 - 00000000, CR3 - 00000000, CR4 - 00000648 DR0 - 00000000, DR1 - 00000000, DR2 - 00000000, DR3 - 00000000 DR6 - FFFF0FF0, DR7 - 00000400 GDTR - 07F7ED90 0000003F, IDTR - 07C5D010 000007FF LDTR - 00000000, TR - 00000000 FXSAVE_STATE - 07FAF800 !!!! Find PE image /home/jljusten/tmp/edk2/Build/OvmfIa32/RELEASE_GCC47/IA32/MdeModulePkg/Core/Pei/PeiMain/DEBUG/PeiCore.dll (ImageBase=07FC8000, EntryPoint=07FC8240) !!!!
-------
64 bit: same as before
I run: qemu-system-x86_64 --nographic --bios ../OVMF-X64/OVMF.fd -hda fat:payload64/efi/
-------
Would it be possible for you to share with me the binary of the EFI payload(s)?
With that I could at lest figure out if the problem is with my qemu/efi configuration or with the payload I'm building.
I doubt this can be the reason, however I'm using gcc (SUSE Linux) 4.8.3 20140627 [gcc-4_8-branch revision 212064]
Hi Igor,
On Fri, Aug 14, 2015 at 5:29 PM, Stoppa, Igor igor.stoppa@intel.com wrote:
Hi Bin, Simon, thanks for your time, unfortunately I'm still having issues, please see below.
On 14 August 2015 at 05:09, Bin Meng bmeng.cn@gmail.com wrote:
I am using QEMU 2.3.0 (built from source) and EFI BIOS (IA32 and X64, built from git source)
I downloaded and built the latest stable QEMU: 2.4.50 according to https://en.wikibooks.org/wiki/QEMU/Linux
And I got the binary EFI firmware from the Tianocore website (http://www.tianocore.org/ovmf/)
Both 32 bit and 64 bit payloads still fail, however not in the same way:
32 bit:
I run qemu-system-i386 --nographic --bios ../OVMF-IA32/OVMF.fd -hda fat:payload32/efi/
Shell> u-boot-payload.efi U-Boot EFI Payload !!!! IA32 Exception Type - 00000006 CPU Apic ID - 00000000 !!!! EIP - FFF00012, CS - 00000010, EFLAGS - 00000046 EAX - 00000000, ECX - 067FA010, EDX - 00000000, EBX - 066EE000 ESP - 07FAFAC0, EBP - 066EE000, ESI - FFF00000, EDI - 07FC0FC8 DS - 00000008, ES - 00000008, FS - 00000008, GS - 00000008, SS - 00000008 CR0 - 40000033, CR2 - 00000000, CR3 - 00000000, CR4 - 00000648 DR0 - 00000000, DR1 - 00000000, DR2 - 00000000, DR3 - 00000000 DR6 - FFFF0FF0, DR7 - 00000400 GDTR - 07F7ED90 0000003F, IDTR - 07C5D010 000007FF LDTR - 00000000, TR - 00000000 FXSAVE_STATE - 07FAF800 !!!! Find PE image /home/jljusten/tmp/edk2/Build/OvmfIa32/RELEASE_GCC47/IA32/MdeModulePkg/Core/Pei/PeiMain/DEBUG/PeiCore.dll (ImageBase=07FC8000, EntryPoint=07FC8240) !!!!
64 bit: same as before
I run: qemu-system-x86_64 --nographic --bios ../OVMF-X64/OVMF.fd -hda fat:payload64/efi/
Would it be possible for you to share with me the binary of the EFI payload(s)?
With that I could at lest figure out if the problem is with my qemu/efi configuration or with the payload I'm building.
I doubt this can be the reason, however I'm using gcc (SUSE Linux) 4.8.3 20140627 [gcc-4_8-branch revision 212064]
I will send it to you offline.
Regards, Bin
Hi Igor,
On Fri, Aug 14, 2015 at 5:34 PM, Bin Meng bmeng.cn@gmail.com wrote:
Hi Igor,
On Fri, Aug 14, 2015 at 5:29 PM, Stoppa, Igor igor.stoppa@intel.com wrote:
Hi Bin, Simon, thanks for your time, unfortunately I'm still having issues, please see below.
On 14 August 2015 at 05:09, Bin Meng bmeng.cn@gmail.com wrote:
I am using QEMU 2.3.0 (built from source) and EFI BIOS (IA32 and X64, built from git source)
I downloaded and built the latest stable QEMU: 2.4.50 according to https://en.wikibooks.org/wiki/QEMU/Linux
And I got the binary EFI firmware from the Tianocore website (http://www.tianocore.org/ovmf/)
Both 32 bit and 64 bit payloads still fail, however not in the same way:
32 bit:
I run qemu-system-i386 --nographic --bios ../OVMF-IA32/OVMF.fd -hda fat:payload32/efi/
Shell> u-boot-payload.efi U-Boot EFI Payload !!!! IA32 Exception Type - 00000006 CPU Apic ID - 00000000 !!!! EIP - FFF00012, CS - 00000010, EFLAGS - 00000046
This is weird address. It should not be such a flash address.
EAX - 00000000, ECX - 067FA010, EDX - 00000000, EBX - 066EE000 ESP - 07FAFAC0, EBP - 066EE000, ESI - FFF00000, EDI - 07FC0FC8 DS - 00000008, ES - 00000008, FS - 00000008, GS - 00000008, SS - 00000008 CR0 - 40000033, CR2 - 00000000, CR3 - 00000000, CR4 - 00000648 DR0 - 00000000, DR1 - 00000000, DR2 - 00000000, DR3 - 00000000 DR6 - FFFF0FF0, DR7 - 00000400 GDTR - 07F7ED90 0000003F, IDTR - 07C5D010 000007FF LDTR - 00000000, TR - 00000000 FXSAVE_STATE - 07FAF800 !!!! Find PE image /home/jljusten/tmp/edk2/Build/OvmfIa32/RELEASE_GCC47/IA32/MdeModulePkg/Core/Pei/PeiMain/DEBUG/PeiCore.dll (ImageBase=07FC8000, EntryPoint=07FC8240) !!!!
64 bit: same as before
I run: qemu-system-x86_64 --nographic --bios ../OVMF-X64/OVMF.fd -hda fat:payload64/efi/
Would it be possible for you to share with me the binary of the EFI payload(s)?
With that I could at lest figure out if the problem is with my qemu/efi configuration or with the payload I'm building.
I doubt this can be the reason, however I'm using gcc (SUSE Linux) 4.8.3 20140627 [gcc-4_8-branch revision 212064]
I will send it to you offline.
OK, I've realized it is a doc issue, that the doc does not mention to change CONFIG_SYS_TEXT_BASE for EFI payload. I will send a patch to update the doc.
Regards, Bin
Hi Bin,
going back to the ml thread for closure
On 14 August 2015 at 12:34, Bin Meng bmeng.cn@gmail.com wrote:
I will send it to you offline.
That one worked on my qemu setup.
So I used the instructions from your patch to the README.efi for replicating it.
* I copied qemu-x86_defconfig to .config and added the following lines:
CONFIG_EFI=y CONFIG_EFI_STUB=y CONFIG_EFI_STUB_32BIT=y
* I run make
and that worked too.
Same for the 64bit payload, after I changed the STUB to 64 bit \o/
Hi Igor,
On Thu, Aug 13, 2015 at 8:46 PM, Stoppa, Igor igor.stoppa@intel.com wrote:
Hi Bin,
On 13 August 2015 at 15:37, Bin Meng bmeng.cn@gmail.com wrote:
x86 architecture ---> Mainboard vendor ---> efi x86 architecture ---> Mainboard model ---> efi
These two should not be changed for EFI payload. What you selected is for EFI application.
Thanks a lot. Now it built. If you don't mind I'll send also for this a patch for making the doc more n00b friendly :-)
I reread the doc and found the only thing that confused you is 'make menuconfig'. Actually it is not needed as the build step of EFI application and payload is pretty clear.
Regards, Bin
Hi Bin,
On 14 August 2015 at 13:30, Bin Meng bmeng.cn@gmail.com wrote:
I reread the doc and found the only thing that confused you is 'make menuconfig'. Actually it is not needed as the build step of EFI application and payload is pretty clear.
Please notice also that not all the options mentioned are immediately available from the qemu_x86_defconfig, so it is not possible to know if they are binary or something else. 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. Maybe the simpler and more effective way to let people easily play with EFI builds of U-Boot is to provide variants of the qemu defconfig file.
Hi Igor,
On Fri, Aug 14, 2015 at 7:22 PM, Stoppa, Igor igor.stoppa@intel.com wrote:
Hi Bin,
On 14 August 2015 at 13:30, Bin Meng bmeng.cn@gmail.com wrote:
I reread the doc and found the only thing that confused you is 'make menuconfig'. Actually it is not needed as the build step of EFI application and payload is pretty clear.
Please notice also that not all the options mentioned are immediately available from the qemu_x86_defconfig, so it is not possible to know if they are binary or something else.
These are Kconfig options. I am not sure what makes you think they are binary?
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.
Maybe the simpler and more effective way to let people easily play with EFI builds of U-Boot is to provide variants of the qemu defconfig file.
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.
Regards, Bin
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
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.
+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
participants (3)
-
Bin Meng -
Simon Glass -
Stoppa, Igor