Hi Quentin/Jonas,

On 14/01/2026 19:29, Jonas Karlman wrote:
> Hi Quentin,
>
> On 1/14/2026 6:08 PM, Quentin Schulz wrote:
>> Hi Jonas,
>>
>> On 1/14/26 4:37 PM, Jonas Karlman wrote:
>>> Hi Quentin,
>>>
>>> On 1/14/2026 4:01 PM, Quentin Schulz wrote:
>>>> Hi Jonas,
>>>>
>>>> On 1/6/26 9:34 PM, Jonas Karlman wrote:
>>>>> With the legacy networking stack, it is possible to use USE_SERVERIP,
>>>>> SERVERIP and BOOTP_PREFER_SERVERIP Kconfg options to force use of a
>>>>> specific TFTP server ip.
>>>>>
>>>>> Using the lwIP networking stack use of the 'tftpserverip' environment
>>>>> variable provide the closest equivalent functionality.
>>>>>
>>>>
>>>> It does read serverip environment variable if it's set, so this should
>>>> match the behavior with the legacy network stack no?
>>>
>>> This is what I first thought, however it seem that the lwip stack differ
>>> slightly from the legacy stack, in that the dhcp lookup always seem to
>>> reset the serverip env var.
>>>
>>>> As for BOOTP_PREFER_SERVERIP, this would need to be implemented in lwip
>>>> and isn't covered by this new variable is it?
>>>
>>> For the lwip stack it looks like the BOOTP_PREFER_SERVERIP Kconfig
>>> option possible was replaced with use of a 'tftpserverip' env var.
>>>
>>> For legacy stack I had something like following in a .config fragment:
>>>
>>>    CONFIG_BOOTP_PREFER_SERVERIP=y
>>>    CONFIG_SERVERIP="192.168.2.50"
>>>    CONFIG_USE_SERVERIP=y
>>>
>>
>> And this meant the serverip would not be overwritten by the dhcp command
>> for example (in the legacy stack)? When doing PXE/TFTP, I always do
>>
>> setenv autoload no; dhcp; setenv serverip X.Y.Z.A; pxe get; pxe boot
>
> I tried to keep it as simple as possible, as I have not used network
> boot before, and used something like following:
>
>   env set boot_targets pxe; bootflow scan -lbG
>
> and when I need to use a USB Ethernet dongle I use something like:
>
>   env delete -f ethaddr; env set boot_targets usb pxe; bootflow scan -lbG
>
>> When I control the DHCP server, I can actually set the TFTP server
>> directly and can skip setting the serverip as it'll be set by the dhcp
>> command correctly it seems?
>
> For my homelab I use UniFi and should be able to control DHCP options,
> however looking at U-Boot it looks like option 66 or 150 is just ignored,
> see [1].
>
>   case 66:    /* Ignore TFTP server name */
>
> [1] 
> https://source.denx.de/u-boot/u-boot/-/blob/master/net/bootp.c?ref_type=heads#L952
>
> From my very limited testing it looks like I am forced to set serverip
> in env and cannot use a DHCP option to set the TFTP server to use.
>
> And when I then also tried lwIP, and that seem to result in new or
> different issues, e.g.:
>
> - lwIP seem to be configured to allow very few packet fragments, trying
>   to use a reasonoble tftp blocksize, e.g. TFTP_BLOCKSIZE=4096 or more
>   seem to cause drop of packets.
>
> - lwIP is very very slow to timeout compared to legacy when serverip
>   point to an invalid TFTP server and pxelinux.cfg files is looked up.
>
> - sometimes got hit with random SError issues when second file was
>   loaded from TFTP, this issue was thankfully fixed with [2].
>
> [2] 
> https://patchwork.ozlabs.org/project/uboot/patch/[email protected]/
>
>>
>>  From my notes, for an OpenWRT DHCP server:
>>
>> Network → DHCP and DNS → PXE/TFTP tab → Add button
>>      Filename: default
>>
>>      Server name: fileserver
>>
>>      Server address: <TFTP server IP address>
>>
>>      Force: checked (may not be necessary)
>>
>> Save & Apply button
>>
>> I'm assuming you need this for your labgrid farm so hopefully you have a
>> way to control the DHCP server :)
>
> Correct, I have been playing around with network boot in my labgrid farm
> and hit a few mines along the way :-)
>
> Should result in a few network related patches in next few days.
>
>>
>>> Adding NET_LWIP=y made pxe booting stop working and 'serverip' always
>>> ended up as the dhpc server regardless if it was set to something else.
>>>
>>
>> Interesting. With tiger-rk3588_defconfig (legacy stack), I get:
>>
>> => setenv serverip 192.192.192.192
>> => setenv autoload no
>> => dhcp
>> ethernet@fe1b0000 Waiting for PHY auto negotiation to complete........ done
>> BOOTP broadcast 1
>> BOOTP broadcast 2
>> BOOTP broadcast 3
>> DHCP client bound to address 10.2.162.193 (1394 ms)
>> => printenv serverip
>> serverip=10.2.0.122
>>
>>> Since lwip instead prioritize the 'tftpserverip' env over the 'serverip'
>>> env for tftp use, adding a similar env var Kconfig option was easy but
>>> may be wrong path?
>>>
>>
>> I don't mind the addition but I'm wondering if it's not a band-aid patch
>> for something else? Maybe lwip missing setting the BOOTP server from a
>> DHCP lease for example?

Quite possibly (I did not check TBH). I think it would be nice to have.

>
> Possible, setting tftp from dhcp also seem to be missing from legacy
> stack, if I am not mistaken. I do think the separation of tftpserverip
> and serverip for lwIP stack at least is a step in right direction, I am
> new to network booting from U-Boot so what do I know :-)

I also find misleading the fact that the legacy net uses 'serverip' for
multiple things, depending on the context. It prevents setting things
globally and makes things a bit more obscure than necessary.

>
> Regards,
> Jonas
>
>>
>>>>
>>>> This patch is fine, I'm just challenging the justification in the commit
>>>> log.

I am also fine with the patch.

Acked-by: Jerome Forissier <[email protected]>

>>>>> Add USE_TFTPSERVERIP and TFTPSERVERIP Kconfig options that can be used
>>>>> to add the 'tftpserverip' environment variable to force use of a
>>>>> specific TFTP server ip.
>>>>>
>>>>> Signed-off-by: Jonas Karlman <[email protected]>
>>>>> ---
>>>>>    include/env_default.h |  3 +++
>>>>>    net/lwip/Kconfig      | 12 ++++++++++++
>>>>>    2 files changed, 15 insertions(+)
>>>>>
>>>>> diff --git a/include/env_default.h b/include/env_default.h
>>>>> index 7f8dc1c35a74..014873e304d8 100644
>>>>> --- a/include/env_default.h
>>>>> +++ b/include/env_default.h
>>>>> @@ -58,6 +58,9 @@ const char default_environment[] = {
>>>>>    #ifdef CONFIG_USE_SERVERIP
>>>>>           "serverip="     CONFIG_SERVERIP                 "\0"
>>>>>    #endif
>>>>> +#ifdef   CONFIG_USE_TFTPSERVERIP
>>>>> + "tftpserverip=" CONFIG_TFTPSERVERIP             "\0"
>>>>> +#endif
>>>>>    #ifdef CONFIG_SYS_DISABLE_AUTOLOAD
>>>>>           "autoload=0\0"
>>>>>    #endif
>>>>> diff --git a/net/lwip/Kconfig b/net/lwip/Kconfig
>>>>> index 5789766fe624..0cfd3eb2684f 100644
>>>>> --- a/net/lwip/Kconfig
>>>>> +++ b/net/lwip/Kconfig
>>>>> @@ -72,4 +72,16 @@ config LWIP_TCP_WND
>>>>>             but QEMU with "-net user" needs no more than a few KB or the
>>>>>             transfer will stall and eventually time out.
>>>>>
>>>>> +config USE_TFTPSERVERIP
>>>>> + bool "Set a default 'tftpserverip' value in the environment"
>>>>> + depends on CMD_TFTPBOOT
>>>>> + help
>>>>> +   Defines a default value for the IP address of a TFTP server to
>>>>> +   contact when using the "tftpboot" command.  (Environment variable
>>>>> +   "tftpserverip")
>>>>> +
>>>>
>>>> Does it support IPv4 *and*/or IPv6?
>>>
>>> Not sure, I have only tested IPv4, guess IPv6 probably should work, the
>>> 'tftpserverip' var should work with same formats that the 'serverip' var
>>> currently support.
>>>
>>> This help text is mostly just a c/p from the USE_SERVERIP Kconfig option,
>>> let me know if you think this should be changed.
>>>
>>
>> If it only supports IPv4, I think it should be mentioned. I'm sure
>> Jerome will have some input on that when they have time to review :)

I haven't tested any IPv6 with lwIP, so at the moment it is considered
unsupported. That said, the lwIP stack itself *does* support IPv6.

Regards,
--
Jerome

>>
>> Cheers,
>> Quentin
>

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

Reply via email to