[PATCH 0/2] efi_loader: efi_setup: Add efi_start_obj_list() and use it to set PXE IP address
The command bootefi calls efi_init_obj_list to do the efi set up before launching an .efi payload, but efi_init_obj_list is called only once. There are some initializations which depend on the environment and should be done each time a payload gets launched and not only once and can now be done in efi_start_obj_list(). A motivation for this change is the following order of events:
1. Launch an EFI application (e.g. bootefi hello) 2. Change the ip address 3. Launch another application which uses the pxe protocol
As the EFI pxe protocol was initialized when the handles for efi net were created in 1., the ip was hardcoded there.
In this example, another possibility would be to make a callback for ip address changes to go all the way up to efi_net.
Adriano Cordova (2): efi_loader: efi_setup: Add efi_start_obj_list() to efi_setup.c efi_loader: efi_net: Add efi_net_start() to efi_net.c
include/efi_loader.h | 1 + lib/efi_loader/efi_net.c | 31 ++++++++++++++++++++++++------- lib/efi_loader/efi_setup.c | 24 +++++++++++++++++++++++- 3 files changed, 48 insertions(+), 8 deletions(-)
The command bootefi calls efi_init_obj_list to do the efi set up before launching an .efi payload, but efi_init_obj_list is called only once. There are some initializations which depend on the environment and should be done each time a payload gets launched and not only once and can now be done in efi_start_obj_list(). A motivation for this change is the following order of events:
1. Launch an EFI application (e.g. bootefi hello) 2. Change the ip address 3. Launch another application which uses the pxe protocol
As the EFI pxe protocol was initialized when the handles for efi net were created in 1., the ip was hardcoded there.
In this example, another possibility would be to make a callback for ip address changes to go all the way up to efi_net.
Signed-off-by: Adriano Cordova adriano.cordova@canonical.com --- lib/efi_loader/efi_setup.c | 21 ++++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c index aa59bc7779..164586742a 100644 --- a/lib/efi_loader/efi_setup.c +++ b/lib/efi_loader/efi_setup.c @@ -12,6 +12,7 @@ #include <log.h> #include <asm-generic/unaligned.h>
+#define OBJ_LIST_INITIALIZED 0 #define OBJ_LIST_NOT_INITIALIZED 1
efi_status_t efi_obj_list_initialized = OBJ_LIST_NOT_INITIALIZED; @@ -208,6 +209,18 @@ out: return -1; }
+/** + * efi_start_obj_list() - Start EFI object list + * + * Return: status code + */ +static efi_status_t efi_start_obj_list(void) +{ + efi_status_t ret = EFI_SUCCESS; + + return ret; +} + /** * efi_init_obj_list() - Initialize and populate EFI object list * @@ -217,7 +230,9 @@ efi_status_t efi_init_obj_list(void) { efi_status_t ret = EFI_SUCCESS;
- /* Initialize once only */ + /* Initialize only once, but start every time if correctly initialized*/ + if (efi_obj_list_initialized == OBJ_LIST_INITIALIZED) + return efi_start_obj_list(); if (efi_obj_list_initialized != OBJ_LIST_NOT_INITIALIZED) return efi_obj_list_initialized;
@@ -349,6 +364,10 @@ efi_status_t efi_init_obj_list(void) if (IS_ENABLED(CONFIG_EFI_CAPSULE_ON_DISK) && !IS_ENABLED(CONFIG_EFI_CAPSULE_ON_DISK_EARLY)) ret = efi_launch_capsules(); + if (ret != EFI_SUCCESS) + goto out; + + ret = efi_start_obj_list(); out: efi_obj_list_initialized = ret; return ret;
On 06.12.24 18:30, Adriano Cordova wrote:
The command bootefi calls efi_init_obj_list to do the efi set up before launching an .efi payload, but efi_init_obj_list is called only once. There are some initializations which depend on the environment and should be done each time a payload gets launched and not only once and can now be done in efi_start_obj_list(). A motivation for this change is the following order of events:
- Launch an EFI application (e.g. bootefi hello)
- Change the ip address
- Launch another application which uses the pxe protocol
Hello Adriano,
Thanks for addressing this issue.
There are a number of events that can lead to updating the IP address:
* EFI_PXE_BASE_CODE_PROTOCOL.Dhcp() * EFI_PXE_BASE_CODE_PROTOCOL.SetStationIp() * EFI_HTTP_PROTOCOL.Configure() * command set env ethaddr# * command dhcp
All of these events require:
* Updating the relevant ethaddr* variable. * Updating any other references to the IP address.
When not only considering EFI applications but also EFI drivers installed via the bootefi command all of these events can occur during the runtime of EFI binaries.
Function efi_init_obj_list() is used for setups that are needed only once before accessing the UEFI sub-system. It is not able to handle events.
If we need to update any internal UEFI data structures, we should do this instantaneously when the event occurs and not when executing a UEFI related shell command.
U-Boot already has callbacks invoked when variables are changed. These are set up with U_BOOT_ENV_CALLBACK(). There is even a command 'env callbacks' to list these callbacks.
You could define a new function to handle changes of the IP address and invoke it via U_BOOT_ENV_CALLBACK(ipaddr, <function name>) or U_BOOT_ENV_CALLBACK(netmask, <function name>).
With lwIP we can have multiple network interfaces. Each has a different variable ipaddr# assigned to it. We will have to extend the concept of U_BOOT_ENV_CALLBACK() to allow for wildcard matches by adjusting find_env_callback(). With CONFIG_REGEX=y regular expressions could be used for this purpose (cf. include/slre.h) but we should better avoid the code size increase.
Best regards
Heinrich
As the EFI pxe protocol was initialized when the handles for efi net were created in 1., the ip was hardcoded there.
In this example, another possibility would be to make a callback for ip address changes to go all the way up to efi_net.
Signed-off-by: Adriano Cordova adriano.cordova@canonical.com
lib/efi_loader/efi_setup.c | 21 ++++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c index aa59bc7779..164586742a 100644 --- a/lib/efi_loader/efi_setup.c +++ b/lib/efi_loader/efi_setup.c @@ -12,6 +12,7 @@ #include <log.h> #include <asm-generic/unaligned.h>
+#define OBJ_LIST_INITIALIZED 0 #define OBJ_LIST_NOT_INITIALIZED 1
efi_status_t efi_obj_list_initialized = OBJ_LIST_NOT_INITIALIZED; @@ -208,6 +209,18 @@ out: return -1; }
+/**
- efi_start_obj_list() - Start EFI object list
- Return: status code
- */
+static efi_status_t efi_start_obj_list(void) +{
- efi_status_t ret = EFI_SUCCESS;
- return ret;
+}
- /**
- efi_init_obj_list() - Initialize and populate EFI object list
@@ -217,7 +230,9 @@ efi_status_t efi_init_obj_list(void) { efi_status_t ret = EFI_SUCCESS;
- /* Initialize once only */
- /* Initialize only once, but start every time if correctly initialized*/
- if (efi_obj_list_initialized == OBJ_LIST_INITIALIZED)
return efi_start_obj_list();@@ -349,6 +364,10 @@ efi_status_t efi_init_obj_list(void) if (IS_ENABLED(CONFIG_EFI_CAPSULE_ON_DISK) && !IS_ENABLED(CONFIG_EFI_CAPSULE_ON_DISK_EARLY)) ret = efi_launch_capsules();
- if (ret != EFI_SUCCESS)
goto out;- ret = efi_start_obj_list(); out: efi_obj_list_initialized = ret; return ret;
Hi Heinrich,
On Fri, 3 Jan 2025 at 12:55, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 06.12.24 18:30, Adriano Cordova wrote:
The command bootefi calls efi_init_obj_list to do the efi set up before launching an .efi payload, but efi_init_obj_list is called only once. There are some initializations which depend on the environment and should be done each time a payload gets launched and not only once and can now be done in efi_start_obj_list(). A motivation for this change is the following order of events:
- Launch an EFI application (e.g. bootefi hello)
- Change the ip address
- Launch another application which uses the pxe protocol
Hello Adriano,
Thanks for addressing this issue.
There are a number of events that can lead to updating the IP address:
- EFI_PXE_BASE_CODE_PROTOCOL.Dhcp()
- EFI_PXE_BASE_CODE_PROTOCOL.SetStationIp()
- EFI_HTTP_PROTOCOL.Configure()
- command set env ethaddr#
- command dhcp
All of these events require:
- Updating the relevant ethaddr* variable.
- Updating any other references to the IP address.
When not only considering EFI applications but also EFI drivers installed via the bootefi command all of these events can occur during the runtime of EFI binaries.
Function efi_init_obj_list() is used for setups that are needed only once before accessing the UEFI sub-system. It is not able to handle events.
If we need to update any internal UEFI data structures, we should do this instantaneously when the event occurs and not when executing a UEFI related shell command.
U-Boot already has callbacks invoked when variables are changed. These are set up with U_BOOT_ENV_CALLBACK(). There is even a command 'env callbacks' to list these callbacks.
You could define a new function to handle changes of the IP address and invoke it via U_BOOT_ENV_CALLBACK(ipaddr, <function name>) or U_BOOT_ENV_CALLBACK(netmask, <function name>).
With lwIP we can have multiple network interfaces. Each has a different variable ipaddr# assigned to it. We will have to extend the concept of U_BOOT_ENV_CALLBACK() to allow for wildcard matches by adjusting find_env_callback(). With CONFIG_REGEX=y regular expressions could be used for this purpose (cf. include/slre.h) but we should better avoid the code size increase.
I have been saying for some time that EFI_LOADER should make use of U-Boot's existing tables, rather than creating its own duplicate ones with extra info.
This seems to have been understood as 'hang the EFI tables onto existing data structures', e.g. efi_disk_create_part(). But this leads to duplication.
Perhaps the EFI_LOADER init should be quite small, and be done each time an app starts, to deal with the 'current' state of U-Boot?
Regards, Simon
Hi Simon,
On Fri, 10 Jan 2025 at 15:41, Simon Glass sjg@chromium.org wrote:
Hi Heinrich,
On Fri, 3 Jan 2025 at 12:55, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 06.12.24 18:30, Adriano Cordova wrote:
The command bootefi calls efi_init_obj_list to do the efi set up before launching an .efi payload, but efi_init_obj_list is called only once. There are some initializations which depend on the environment and should be done each time a payload gets launched and not only once and can now be done in efi_start_obj_list(). A motivation for this change is the following order of events:
- Launch an EFI application (e.g. bootefi hello)
- Change the ip address
- Launch another application which uses the pxe protocol
Hello Adriano,
Thanks for addressing this issue.
There are a number of events that can lead to updating the IP address:
- EFI_PXE_BASE_CODE_PROTOCOL.Dhcp()
- EFI_PXE_BASE_CODE_PROTOCOL.SetStationIp()
- EFI_HTTP_PROTOCOL.Configure()
- command set env ethaddr#
- command dhcp
All of these events require:
- Updating the relevant ethaddr* variable.
- Updating any other references to the IP address.
When not only considering EFI applications but also EFI drivers installed via the bootefi command all of these events can occur during the runtime of EFI binaries.
Function efi_init_obj_list() is used for setups that are needed only once before accessing the UEFI sub-system. It is not able to handle events.
If we need to update any internal UEFI data structures, we should do this instantaneously when the event occurs and not when executing a UEFI related shell command.
U-Boot already has callbacks invoked when variables are changed. These are set up with U_BOOT_ENV_CALLBACK(). There is even a command 'env callbacks' to list these callbacks.
You could define a new function to handle changes of the IP address and invoke it via U_BOOT_ENV_CALLBACK(ipaddr, <function name>) or U_BOOT_ENV_CALLBACK(netmask, <function name>).
With lwIP we can have multiple network interfaces. Each has a different variable ipaddr# assigned to it. We will have to extend the concept of U_BOOT_ENV_CALLBACK() to allow for wildcard matches by adjusting find_env_callback(). With CONFIG_REGEX=y regular expressions could be used for this purpose (cf. include/slre.h) but we should better avoid the code size increase.
I have been saying for some time that EFI_LOADER should make use of U-Boot's existing tables, rather than creating its own duplicate ones with extra info.
This seems to have been understood as 'hang the EFI tables onto existing data structures', e.g. efi_disk_create_part(). But this leads to duplication.
Perhaps the EFI_LOADER init should be quite small, and be done each time an app starts, to deal with the 'current' state of U-Boot?
That would break all the command line tools that use the EFI subsystem -- e.g printenv -e, efidebug, eficonfig etc /Ilias
Regards, Simon
Hi Ilias,
On Fri, 10 Jan 2025 at 07:15, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
Hi Simon,
On Fri, 10 Jan 2025 at 15:41, Simon Glass sjg@chromium.org wrote:
Hi Heinrich,
On Fri, 3 Jan 2025 at 12:55, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 06.12.24 18:30, Adriano Cordova wrote:
The command bootefi calls efi_init_obj_list to do the efi set up before launching an .efi payload, but efi_init_obj_list is called only once. There are some initializations which depend on the environment and should be done each time a payload gets launched and not only once and can now be done in efi_start_obj_list(). A motivation for this change is the following order of events:
- Launch an EFI application (e.g. bootefi hello)
- Change the ip address
- Launch another application which uses the pxe protocol
Hello Adriano,
Thanks for addressing this issue.
There are a number of events that can lead to updating the IP address:
- EFI_PXE_BASE_CODE_PROTOCOL.Dhcp()
- EFI_PXE_BASE_CODE_PROTOCOL.SetStationIp()
- EFI_HTTP_PROTOCOL.Configure()
- command set env ethaddr#
- command dhcp
All of these events require:
- Updating the relevant ethaddr* variable.
- Updating any other references to the IP address.
When not only considering EFI applications but also EFI drivers installed via the bootefi command all of these events can occur during the runtime of EFI binaries.
Function efi_init_obj_list() is used for setups that are needed only once before accessing the UEFI sub-system. It is not able to handle events.
If we need to update any internal UEFI data structures, we should do this instantaneously when the event occurs and not when executing a UEFI related shell command.
U-Boot already has callbacks invoked when variables are changed. These are set up with U_BOOT_ENV_CALLBACK(). There is even a command 'env callbacks' to list these callbacks.
You could define a new function to handle changes of the IP address and invoke it via U_BOOT_ENV_CALLBACK(ipaddr, <function name>) or U_BOOT_ENV_CALLBACK(netmask, <function name>).
With lwIP we can have multiple network interfaces. Each has a different variable ipaddr# assigned to it. We will have to extend the concept of U_BOOT_ENV_CALLBACK() to allow for wildcard matches by adjusting find_env_callback(). With CONFIG_REGEX=y regular expressions could be used for this purpose (cf. include/slre.h) but we should better avoid the code size increase.
I have been saying for some time that EFI_LOADER should make use of U-Boot's existing tables, rather than creating its own duplicate ones with extra info.
This seems to have been understood as 'hang the EFI tables onto existing data structures', e.g. efi_disk_create_part(). But this leads to duplication.
Perhaps the EFI_LOADER init should be quite small, and be done each time an app starts, to deal with the 'current' state of U-Boot?
That would break all the command line tools that use the EFI subsystem -- e.g printenv -e, efidebug, eficonfig etc
Obviously we would not do it in such a way as to break anything! I'm not quite sure if that is was a serious comment, or just a reminder that we should not break things?
As a very simple example, somewhat unrelated to this patch, rather than maintaining its own efi_cout_modes[], it could make use of U-Boot's information.
There is quite a bit of effort involved in maintaining two separate states. It started from a design to run independently of driver model (which was a mistake), but has since become common in many areas. It means that a special, heavyweight 'init' has to be done and we need to pick when that is done and how to update it later. We should chart a slightly different course and chip away at this problem.
Regards, Simon
On 10.01.25 14:40, Simon Glass wrote:
Hi Heinrich,
On Fri, 3 Jan 2025 at 12:55, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 06.12.24 18:30, Adriano Cordova wrote:
The command bootefi calls efi_init_obj_list to do the efi set up before launching an .efi payload, but efi_init_obj_list is called only once. There are some initializations which depend on the environment and should be done each time a payload gets launched and not only once and can now be done in efi_start_obj_list(). A motivation for this change is the following order of events:
- Launch an EFI application (e.g. bootefi hello)
- Change the ip address
- Launch another application which uses the pxe protocol
Hello Adriano,
Thanks for addressing this issue.
There are a number of events that can lead to updating the IP address:
- EFI_PXE_BASE_CODE_PROTOCOL.Dhcp()
- EFI_PXE_BASE_CODE_PROTOCOL.SetStationIp()
- EFI_HTTP_PROTOCOL.Configure()
- command set env ethaddr#
- command dhcp
All of these events require:
- Updating the relevant ethaddr* variable.
- Updating any other references to the IP address.
When not only considering EFI applications but also EFI drivers installed via the bootefi command all of these events can occur during the runtime of EFI binaries.
Function efi_init_obj_list() is used for setups that are needed only once before accessing the UEFI sub-system. It is not able to handle events.
If we need to update any internal UEFI data structures, we should do this instantaneously when the event occurs and not when executing a UEFI related shell command.
U-Boot already has callbacks invoked when variables are changed. These are set up with U_BOOT_ENV_CALLBACK(). There is even a command 'env callbacks' to list these callbacks.
You could define a new function to handle changes of the IP address and invoke it via U_BOOT_ENV_CALLBACK(ipaddr, <function name>) or U_BOOT_ENV_CALLBACK(netmask, <function name>).
With lwIP we can have multiple network interfaces. Each has a different variable ipaddr# assigned to it. We will have to extend the concept of U_BOOT_ENV_CALLBACK() to allow for wildcard matches by adjusting find_env_callback(). With CONFIG_REGEX=y regular expressions could be used for this purpose (cf. include/slre.h) but we should better avoid the code size increase.
I have been saying for some time that EFI_LOADER should make use of U-Boot's existing tables, rather than creating its own duplicate ones with extra info.
What structures are you referring to concerning this patch?
This seems to have been understood as 'hang the EFI tables onto existing data structures', e.g. efi_disk_create_part(). But this leads to duplication.
We have to present the U-Boot DM devices in a way that an EFI binary can consume.
Unless U-Boot's DM-layer is re-implemented via EFI structures we will end up with two representations.
Perhaps the EFI_LOADER init should be quite small, and be done each time an app starts, to deal with the 'current' state of U-Boot?
No, we can load both EFI apps and EFI drivers with the bootefi command. In the case of EFI drivers we must not remove the handles and protocols representing U-Boot DM devices after the binaries return.
Best regards
Heinrich
Hi Heinrich,
On Fri, 10 Jan 2025 at 08:13, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 10.01.25 14:40, Simon Glass wrote:
Hi Heinrich,
On Fri, 3 Jan 2025 at 12:55, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 06.12.24 18:30, Adriano Cordova wrote:
The command bootefi calls efi_init_obj_list to do the efi set up before launching an .efi payload, but efi_init_obj_list is called only once. There are some initializations which depend on the environment and should be done each time a payload gets launched and not only once and can now be done in efi_start_obj_list(). A motivation for this change is the following order of events:
- Launch an EFI application (e.g. bootefi hello)
- Change the ip address
- Launch another application which uses the pxe protocol
Hello Adriano,
Thanks for addressing this issue.
There are a number of events that can lead to updating the IP address:
- EFI_PXE_BASE_CODE_PROTOCOL.Dhcp()
- EFI_PXE_BASE_CODE_PROTOCOL.SetStationIp()
- EFI_HTTP_PROTOCOL.Configure()
- command set env ethaddr#
- command dhcp
All of these events require:
- Updating the relevant ethaddr* variable.
- Updating any other references to the IP address.
When not only considering EFI applications but also EFI drivers installed via the bootefi command all of these events can occur during the runtime of EFI binaries.
Function efi_init_obj_list() is used for setups that are needed only once before accessing the UEFI sub-system. It is not able to handle events.
If we need to update any internal UEFI data structures, we should do this instantaneously when the event occurs and not when executing a UEFI related shell command.
U-Boot already has callbacks invoked when variables are changed. These are set up with U_BOOT_ENV_CALLBACK(). There is even a command 'env callbacks' to list these callbacks.
You could define a new function to handle changes of the IP address and invoke it via U_BOOT_ENV_CALLBACK(ipaddr, <function name>) or U_BOOT_ENV_CALLBACK(netmask, <function name>).
With lwIP we can have multiple network interfaces. Each has a different variable ipaddr# assigned to it. We will have to extend the concept of U_BOOT_ENV_CALLBACK() to allow for wildcard matches by adjusting find_env_callback(). With CONFIG_REGEX=y regular expressions could be used for this purpose (cf. include/slre.h) but we should better avoid the code size increase.
I have been saying for some time that EFI_LOADER should make use of U-Boot's existing tables, rather than creating its own duplicate ones with extra info.
What structures are you referring to concerning this patch?
I gave the example of efi_cout_modes[]. I suspect quite a lot of structures could be relationalised.
This seems to have been understood as 'hang the EFI tables onto existing data structures', e.g. efi_disk_create_part(). But this leads to duplication.
We have to present the U-Boot DM devices in a way that an EFI binary can consume.
Unless U-Boot's DM-layer is re-implemented via EFI structures we will end up with two representations.
I believe we can reduce the amount of duplication, in general. I'm not just thinking about driver model. The EFI loader was originally designed to avoid dependence on driver model (I can provide the thread if you like), so even there, I believe improvement is possible.
Perhaps the EFI_LOADER init should be quite small, and be done each time an app starts, to deal with the 'current' state of U-Boot?
No, we can load both EFI apps and EFI drivers with the bootefi command. In the case of EFI drivers we must not remove the handles and protocols representing U-Boot DM devices after the binaries return.
My question is whether these can be generated based on the available objects, with just a small amount of data kept in the dm struct, or whether they must be in a separate data structure?
Regards, SImon
This gets called each time a payload is to get executed by bootefi. For now this only updates the PXE IP address.
Signed-off-by: Adriano Cordova adriano.cordova@canonical.com --- include/efi_loader.h | 1 + lib/efi_loader/efi_net.c | 31 ++++++++++++++++++++++++------- lib/efi_loader/efi_setup.c | 3 +++ 3 files changed, 28 insertions(+), 7 deletions(-)
diff --git a/include/efi_loader.h b/include/efi_loader.h index 0d858c1e12..85ca0ecee1 100644 --- a/include/efi_loader.h +++ b/include/efi_loader.h @@ -626,6 +626,7 @@ int efi_disk_create_partitions(efi_handle_t parent, struct blk_desc *desc, efi_status_t efi_gop_register(void); /* Called by bootefi to make the network interface available */ efi_status_t efi_net_register(void); +efi_status_t efi_net_do_start(void); /* Called by efi_net_register to make the ip4 config2 protocol available */ efi_status_t efi_ipconfig_register(const efi_handle_t handle, struct efi_ip4_config2_protocol *ip4config); diff --git a/lib/efi_loader/efi_net.c b/lib/efi_loader/efi_net.c index ac8e54639b..acb71ef12a 100644 --- a/lib/efi_loader/efi_net.c +++ b/lib/efi_loader/efi_net.c @@ -876,6 +876,30 @@ static efi_status_t EFIAPI efi_pxe_base_code_set_packets( return EFI_UNSUPPORTED; }
+/** + * efi_net_do_start() - start the efi network stack + * + * This gets called from do_bootefi_exec() each time a payload gets executed. + * + * Return: status code + */ +efi_status_t efi_net_do_start(void) +{ + efi_status_t r = EFI_SUCCESS; + +#ifdef CONFIG_EFI_HTTP_PROTOCOL + /* + * No harm on doing the following. If the PXE handle is present, the client could + * find it and try to get its IP address from it. In here the PXE handle is present + * but the PXE protocol is not yet implmenented, so we add this in the meantime. + */ + efi_net_get_addr((struct efi_ipv4_address *)&netobj->pxe_mode.station_ip, + (struct efi_ipv4_address *)&netobj->pxe_mode.subnet_mask, NULL); +#endif + + return r; +} + /** * efi_net_register() - register the simple network protocol * @@ -1020,13 +1044,6 @@ efi_status_t efi_net_register(void) r = efi_http_register(&netobj->header, &netobj->http_service_binding); if (r != EFI_SUCCESS) goto failure_to_add_protocol; - /* - * No harm on doing the following. If the PXE handle is present, the client could - * find it and try to get its IP address from it. In here the PXE handle is present - * but the PXE protocol is not yet implmenented, so we add this in the meantime. - */ - efi_net_get_addr((struct efi_ipv4_address *)&netobj->pxe_mode.station_ip, - (struct efi_ipv4_address *)&netobj->pxe_mode.subnet_mask, NULL); #endif
return EFI_SUCCESS; diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c index 164586742a..eeed82c073 100644 --- a/lib/efi_loader/efi_setup.c +++ b/lib/efi_loader/efi_setup.c @@ -218,6 +218,9 @@ static efi_status_t efi_start_obj_list(void) { efi_status_t ret = EFI_SUCCESS;
+ if (IS_ENABLED(CONFIG_NETDEVICES)) + ret = efi_net_do_start(); + return ret; }
On Fri, Dec 06, 2024 at 02:30:31PM -0300, Adriano Cordova wrote:
The command bootefi calls efi_init_obj_list to do the efi set up before launching an .efi payload, but efi_init_obj_list is called only once. There are some initializations which depend on the environment and should be done each time a payload gets launched and not only once and can now be done in efi_start_obj_list(). A motivation for this change is the following order of events:
- Launch an EFI application (e.g. bootefi hello)
- Change the ip address
- Launch another application which uses the pxe protocol
As the EFI pxe protocol was initialized when the handles for efi net were created in 1., the ip was hardcoded there.
In this example, another possibility would be to make a callback for ip address changes to go all the way up to efi_net.
Adriano Cordova (2): efi_loader: efi_setup: Add efi_start_obj_list() to efi_setup.c efi_loader: efi_net: Add efi_net_start() to efi_net.c
include/efi_loader.h | 1 + lib/efi_loader/efi_net.c | 31 ++++++++++++++++++++++++------- lib/efi_loader/efi_setup.c | 24 +++++++++++++++++++++++- 3 files changed, 48 insertions(+), 8 deletions(-)
On top of the previous series that fixed my other issue:
Tested-by: Tom Rini trini@konsulko.com
participants (5)
-
Adriano Cordova -
Heinrich Schuchardt -
Ilias Apalodimas -
Simon Glass -
Tom Rini