Am 2. Juni 2025 20:06:08 MESZ schrieb E Shattow <e...@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.foriss...@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 <thar...@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
