[PATCH 0/3] sntp for NET_LWIP

[Heinrich Schuchardt]

Am 2. Juni 2025 20:06:08 MESZ schrieb E Shattow <e at freeshell.de>:
>
>
>On 6/2/25 01:11, Jerome Forissier wrote:
>> Hi Tim,
>> 
>> On 5/30/25 17:46, Tim Harvey wrote:
>>> On Wed, May 21, 2025 at 8:15 AM Jerome Forissier
>>> <jerome.forissier at linaro.org> wrote:
>>>>
>>>> Implement the sntp command with lwIP (CONFIG_NET_LWIP=y). SNTP is
>>>> supported as an app in lib/lwip/lwip/src/apps/sntp/sntp.c so this is
>>>> mainly about adding that file to the build and writing do_sntp() to use
>>>> the sntp_*() API and run the receive & timer loop. There is a patch to
>>>> extract a small bit of common code from net/sntp.c to avoid duplication.
>>>> The QEMU arm64 lwIP defconfig is updated to provide the sntp command by
>>>> default for convenience.
>>>> I could not test the case when the NTP server IP is provided by DHCP. If
>>>> someone has access right away to such a configuration and in case it
>>>> does not work, please let me know.
>>>>
>>>>
>>>> Jerome Forissier (3):
>>>>   net: extract function net_sntp_set_rtc() from sntp_handler()
>>>>   net: lwip: add sntp command
>>>>   configs: qemu_arm64_lwip_defconfig: enable CMD_SNTP
>>>>
>>>>  cmd/Kconfig                       |  13 +--
>>>>  cmd/net-lwip.c                    |   5 ++
>>>>  configs/qemu_arm64_lwip_defconfig |   1 +
>>>>  include/net-common.h              |  13 +++
>>>>  lib/lwip/Makefile                 |   1 +
>>>>  lib/lwip/u-boot/arch/cc.h         |   4 +
>>>>  lib/lwip/u-boot/lwipopts.h        |   4 +
>>>>  net/lwip/Makefile                 |   1 +
>>>>  net/lwip/sntp.c                   | 128 ++++++++++++++++++++++++++++++
>>>>  net/net-common.c                  |  28 +++++++
>>>>  net/sntp.c                        |  23 +-----
>>>>  11 files changed, 195 insertions(+), 26 deletions(-)
>>>>  create mode 100644 net/lwip/sntp.c
>>>>
>>>
>>> Hi Jerome,
>>>
>>> Thanks for the continued work on lwIP!
>> 
>> Sure. Thank you for testing and fixing bugs :)
>>  
>>> For the series:
>>> Reviewed-by: Tim Harvey <tharvey at gateworks.com>
>>>
>>> Note that if this is merged before my series we'll want to have a
>>> followup that removes the sys_check_timeouts() after net_lwip_rx(udev,
>>> netif), or if it is merged before my series I can send a v3 that does
>>> it.
>> 
>> Both series are in my patchwork queue, so I'll take care of that. Thanks
>> for the heads up.
>> 
>>> Do you have a list of lwIP features you're still working on? I'm going
>>> to be moving the Gateworks venice boards to it as things look pretty
>>> good. The only thing I saw that was missing was TFTPPUT which I don't
>>> really care about.
>> 
>> I don't have any thing left in my to-do list for lwIP at the moment. There
>> are several U-Boot features that are still not supported with NET_LWIP. As
>> you said TFTP PUT but also IPv6, the bootp command, as well as ncsi, ethsw,
>> and wol (those are found in cmd/Kconfig). Maybe other things, I don't know.
>> 
>> BR,
>
>Getting data off from the U-Boot device under test is missing some
>similar function today. It would be enough to re-implement tftpput but I
>rather like the convenience of "wget" to do everything from host and
>from U-Boot device.
>
>Before LwIP and missing tftpput I did use tftpput:
>
>1. Send data from memory address range read from some flash peripheral
>
>2. Send data from files on attached storage filesystem (repeat
>intermediate step to read each file to memory address).
>
>The tftpput command is useful for (1) and is a problem for (2).
>
>Suggestion is an HTTP server command to respond with data from a memory
>address range or device filesystem i.e.:
>
>httpd <[<address> <size>]|[<interface> [<dev[:part]>]> [filename]
>
>The command responds to HTTP GET requests until a simple timeout in
>seconds (default 0 no timeout), probably as an environment variable.
>There might also be an environment variable to limit the maximum number
>of requests handled (default 0 for unlimited) so that you could use this
>in a script as a kind of network operated trigger or automation.
>
>When first parameter is a valid memory address (default $loadaddr) then
>second parameter (default $filesize) is the size. A size of 0 is valid
>and does not read from the memory address also returns no data. Optional
>third parameter unspecified or default responds to any GET request. If
>third parameter is specified then only respond to GET request for that
>filename with any leading pathname stripped from the parameter.
>
>This would allow to simply command `httpd` after some other memory read
>operation which has set env variables for us, and optionally `httpd - -
>"filename"` if we want to be selective about the GET request that will
>read our data. For an HTTP request viewer specify `httpd - 0` or in a
>script for example if you want to hold up script execution until a
>certain number of valid network requests for "secret" resource but don't
>care about the return data, something like `httpd - 0 "secret"` and the
>appropriate environment variable to limit successful responses before exit.
>
>If first parameter not a valid memory address, then we assume a similar
>invocation as `ls`. When responding to a request if filename parameter
>is then a valid directory respond with a directory listing, else serve
>that file. File not found is 404 response but does not exit.
>
>This overloading of both memory address and device filesystem works if
>there are not any devices that are named with address values. If that is
>too much then split to `httpd` and `httpdmem` i.e. two commands.
>
>Overall with LwIP adding HTTP `wget` command we are able to simply start
>a host HTTP server to get files from, and this is easy on most host
>systems that have Python lang:
>
>$ python3 -m http.server 8080
>
>I hope this description is useful?
>
>- E Shattow

Implementing a robust and safe HTTP server is not trivial.

If you want to use http to transport a file out of U-Boot, you should implement a HTTP POST command.

https://pypi.org/project/uploadserver/ allows you to easily spin up an HTTP server.

I would favor focussing on reaching feature parity to eliminate the old network stack before implementing new features.

Best regards

Heinrich