On Mon, Jun 02, 2025 at 08:35:31PM +0200, Heinrich Schuchardt wrote: > 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.
I would second looking down the path of adding HTTP POST support first, and then documenting spinning up a trivial http server to accept the upload, rather than adding http server support. -- Tom
signature.asc
Description: PGP signature
