Hi Quentin,
On 1/15/2026 3:20 PM, Quentin Schulz wrote:
> Hi Jonas,
>
> On 1/14/26 7:29 PM, 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.
>>
>
> Still on my RK3588 Tiger (on a different network, legacy stack):
>
> => env set boot_targets pxe; bootflow scan -lbG
> Scanning for bootflows in all bootdevs
> Seq Method State Uclass Part Name Filename
> --- ----------- ------ -------- ---- ------------------------
> ----------------
> pcie_dw_rockchip pcie@fe150000: PCIe-0 Link Fail
> Scanning bootdev '[email protected]':
> ethernet@fe1b0000 Waiting for PHY auto negotiation to complete...... done
> BOOTP broadcast 1
> DHCP client bound to address 192.168.1.144 (5 ms)
> missing environment variable: pxeuuid
> Retrieving file: pxelinux.cfg/01-aa-38-40-51-be-af
> Using ethernet@fe1b0000 device
> TFTP from server 192.168.1.211; our IP address is 192.168.1.144
>
> My DHCP server is on OpenWRT at 192.168.1.1, and my TFTP server is on
> 192.168.1.211, with the setup steps explained in my first answer. If I
> don't boot (remove -b), then I can see serverip is set to 192.168.1.211.
>
> So *something* is working here.
I took a closer look at how the UniFi dnsmasq config was generated and
noticed that I must configure the "Network Boot" option and not the
"TFTP Server" option to have a generated config that make dnsmasq
replace the DHCP siaddr field with the TFTP server ip :-S
And legacy stack seem to work as expected and correctly uses the
expected siaddr field to configure the internal net_server_ip var.
Following diff seem to make lwIP also pick up the siaddr as the
tftpserverip (in addition to serverip for the DHCP server):
diff --git a/net/lwip/dhcp.c b/net/lwip/dhcp.c
index 731b57de3ba4..a3445a48b15d 100644
--- a/net/lwip/dhcp.c
+++ b/net/lwip/dhcp.c
@@ -99,8 +99,11 @@ static int dhcp_loop(struct udevice *udev)
env_set(ipstr, ip4addr_ntoa(&dhcp->offered_ip_addr));
env_set(maskstr, ip4addr_ntoa(&dhcp->offered_sn_mask));
env_set("serverip", ip4addr_ntoa(&dhcp->server_ip_addr));
- if (dhcp->offered_gw_addr.addr != 0)
+ if (!ip4_addr_isany(&dhcp->offered_gw_addr))
env_set(gwstr, ip4addr_ntoa(&dhcp->offered_gw_addr));
+ if (!ip4_addr_isany(&dhcp->offered_si_addr) &&
+ !ip4_addr_eq(&dhcp->offered_si_addr, &dhcp->server_ip_addr))
+ env_set("tftpserverip", ip4addr_ntoa(&dhcp->offered_si_addr));
#ifdef CONFIG_PROT_DNS_LWIP
env_set("dnsip", ip4addr_ntoa(dns_getserver(0)));
With something like that I do not think I will have any further use of
SERVERIP or TFTPSERVERIP Kconfig options for my labgrid farm, so can
probably drop this series and will instead send above diff as a separate
patch.
>> 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].
>>
>
> Rough first experience with lwIP :)
Hehe, and all while trying to figure out why dwc_eth_qos was not working
on my Rockchip RK3506 board (firewall blocked DMA to DRAM) and my
AX88179A/AX88772D USB Ethernet adapters also had driver issues :-D
At least this experience has helped generate a few forthcoming cleanup
patches for dwc_eth_qos and asix88179 drivers.
> Are you planning on new Rockchip board/SoC support to use lwIP?
Not sure, but at some point we probably should fully switch to use lwIP
for the Rockchip platform. The LWIP_DEBUG and LWIP_DEBUG_RXTX Kconfig
options can help a lot when debugging any issue with Ethernet drivers.
Regards,
Jonas
>> [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?
>>
>> 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'm not sure the point of lwip is to keep all the quirks from the legacy
> stack, but it doesn't hurt to bring this up :)
>
> Cheers,
> Quentin
