- Oct 16, 2024
-
-
Add support for the wget command with NET_LWIP. The command normally expects a URL: wget [loadaddr] url, but it also accepts the legacy syntax: wget [loadaddr] [server:]file. The server IP may alternatively be supplied via ${httpserverip} which has higher priority than ${serverip}. Based on code initially developed by Maxim U. Signed-off-by:Jerome Forissier <jerome.forissier@linaro.org> Co-developed-by:
Maxim Uvarov <muvarov@gmail.com> Cc: Maxim Uvarov <muvarov@gmail.com> Signed-off-by:
Ilias Apalodimas <ilias.apalodimas@linaro.org>
-
Extract some code from cmd/net.c that will be useful in a subsequent commit to implement wget with NET_LWIP. Signed-off-by:
-
Add CMD_DNS when NET_LWIP is enabled to provide the dns command using lwIP. Signed-off-by:
-
Add support for the the ping command with NET_LWIP. The implementation is derived from lwIP's contrib/apps/ping/ping.c. Signed-off-by:
-
Implement do_tftpb(). This implementation of the tftp command supports an optional port number. For example: tftp 192.168.0.30:9069:file.bin It also supports taking the server IP from ${tftpserverip} if defined, before falling back to ${serverip}. Signed-off-by: -
The TFTP app should not bind to the TFTP server port when configured as a client. Instead, the local port should be chosen from the dynamic range (49152 ~ 65535) so that if the application is stopped and started again, the remote server will not consider the new packets as part of the same context (which would cause an error since a new RRQ would be unexpected). Submitted upstream: https://savannah.nongnu.org/patch/?10480 Signed-off-by:
-
Add what it takes to enable NETDEVICES with NET_LWIP and enable DHCP as well as the dhcp command. CMD_TFTPBOOT is selected by BOOTMETH_EFI due to this code having an implicit dependency on do_tftpb(). Note that PXE is likely non-fonctional with NET_LWIP (or at least not 100% functional) because DHCP option 209 is not supported by the lwIP library. Therefore, BOOTP_PXE_DHCP_OPTION cannot be enabled. Signed-off-by:
-
Build the lwIP library when NET_LWIP is enabled. The following files are adaptation layers written specially for U-Boot: lib/lwip/u-boot/arch/cc.h lib/lwip/u-boot/arch/sys_arch.h (empty) lib/lwip/u-boot/limits.h (empty) lib/lwip/u-boot/lwipopts.h They were initially contributed by Maxim in a previous RFC patch series. The lwIP stack needs to be added as a Git subtree with the following command: $ git subtree add --squash --prefix lib/lwip/lwip \ https://github.com/lwip-tcpip/lwip.git STABLE-2_2_0_RELEASE Signed-off-by:
-
Add a function to start a given network device, and update eth_init() to use it. Signed-off-by:
-
Make net.h a wrapper which includes net-common.h and either net-legacy.h or net-lwip.h based on NET_LWIP. The function copy_filename() can be useful when NET_LWIP is enabled, therefore move it out of net/net.c which is built only when networking choice is NET and create a new file net/net-common.c. Signed-off-by:
-
Prepare the introduction of the lwIP (lightweight IP) TCP/IP stack by adding a new net/lwip/ directory and the NET_LWIP symbol. Network support is either NO_NET, NET (legacy stack) or NET_LWIP. Subsequent commits will introduce the lwIP code, re-work the NETDEVICE integration and port some of the NET commands and features to lwIP. SPL_NET cannot be enabled when NET_LWIP=y. SPL_NET pulls some symbols that are part of NET (such as arp_init(), arp_timeout_check(), arp_receive(), net_arp_wait_packet_ip()). lwIP support in SPL may be added later. Similarly, DFU_TFTP and FASTBOOT are not compatible with NET_LWIP because of dependencies on net_loop(), tftp_timeout_ms, tftp_timeout_count_max and other NET things. Let's add a dependency on !NET_LWIP for now. SANDBOX can select NET_LWIP but doing so will currently disable the eth dm tests as well as the wget tests which have strong dependencies on the NET code. Other adjustments to Kconfig files are made to fix "unmet direct dependencies detected" for USB_FUNCTION_SDP and CMD_FASTBOOT when the default networking stack is set to NET_LWIP ("default NET_LWIP" instead of "default NET" in Kconfig). The networking stack is now a choice between NO_NET, NET and NET_LWIP. Therefore '# CONFIG_NET is not set' should be 'CONFIG_NO_NET=y'. Adjust the defconfigs accordingly. Signed-off-by: -
When DSA_SANDBOX is not set, the sandbox tests fail as follows: $ ./test/py/test.py --build-dir=$(pwd) -k bootdev_test_any [...] Scanning for bootflows with label '9' [...] Cannot find '9' (err=-19) This is due to the device list containing two less entries than expected. Therefore, look for label '7' when DSA_SANDBOX is disabled. The actual use case is NET_LWIP=y (to be introduced in later patches) which implies DSA_SANDBOX=n for the time being. Signed-off-by: -
When DSA_SANDBOX is not set, the sandbox tests fail as follows: $ ./test/py/test.py --build-dir=$(pwd) -k bootdev_test_any [...] Test: bootdev_test_any: bootdev.c test/boot/bootdev.c:156, bootdev_test_any(): "mmc2" = media->name: Expected "mmc2", got "mmc0" [...] This is due to the device list containing two less entries than expected. Therefore, adjust the expected index to be two less when DSA_SANDBOX is disabled. The actual use case is NET_LWIP=y (to be introduced in later patches) which implies DSA_SANDBOX=n for the time being. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Introduce ETH_SANDBOX_LWIP which enables a mock driver similar to ETH_SANDOX but without the dependencies on the legacy network stack (NET) so that it may be enabled when the lwIP stack (NET_LWIP) is introduced. The driver does nothing at this stage but its presence will allow dm_test_iommu_noiommu [1] to pass. [1] ./u-boot -T -c "ut dm dm_test_iommu_noiommu" Signed-off-by:
-
The tools-only defconfig causes troubles on MacOSX due to the default C compiler being Clang (LLVM) rather than GCC and more specifically due to [1]. Therefore replace "# CONFIG_FOO is not set" with the equivalent "CONFIG_FOO=n" using the following command: $ sed -i -e 's/# \(CONFIG_[^ ]*\) is not set/\1=n/' \ configs/tools-only_defconfig This fixes the tools_only_macOS CI job on GitHub [2]. [1] https://github.com/llvm/llvm-project/issues/78778 [2] https://dev.azure.com/u-boot/u-boot/_build/results?buildId=9105&view=results Suggested-by:Tom Rini <trini@konsulko.com> Signed-off-by:
-
Tom Rini authored
-
Tom Rini authored
git-subtree-dir: lib/lwip/lwip git-subtree-split: 0a0452b2c39bdd91e252aef045c115f88f6ca773
-
Tom Rini authored
:hile we had hoped to be able to remove these options finally, it was missed that zynq still requires these currently. This reverts commit 5b9261fb and commit 099b6df5. Reported-by:
Jonas Karlman <jonas@kwiboo.se> Signed-off-by:
-
- Oct 15, 2024
-
-
-
Tom Rini authored
Sughosh Ganu <sughosh.ganu@linaro.org> says: This is part two of the series to have the EFI and LMB modules have a coherent view of memory. Part one of this goal was to change the LMB module to have a global and persistent memory map. Those patches have now been applied to the next branch. These patches are changing the EFI memory allocation API's such that they rely on the LMB module to allocate RAM memory. This fixes the current scenario where the EFI memory module has no visibility of the allocations/reservations made by the LMB module. One thing to note here is that this is limited to the RAM memory region, i.e. the EFI_CONVENTIONAL_MEMORY type. Any other memory type that is to be added to the EFI memory map, still gets handled by the EFI memory module. Changes since V3: * Add comments for the LMB_NOOVERWRITE and LMB_NONOTIFY flags * Drop use of is_addr_in_ram() function * Drop use of CONFIG_MEM_MAP_UPDATE_NOTIFY symbol to check if the notification needs to be sent. * s/lmb_notify/lmb_should_notify * Put a check for EFI_LOADER in the lmb_should_notify() function Some test logs to highlight the issue that is being fixed by the series. Without patch series -------------------- lmb_dump_all: memory.count = 0x1 memory[0] [0x40000000-0x820fffff], 0x42100000 bytes flags: none reserved.count = 0x3 reserved[0] [0xe100000-0xeffffff], 0x00f00000 bytes flags: no-map reserved[1] [0x42000000-0x421fffff], 0x00200000 bytes flags: no-map reserved[2] [0x7f77da00-0x820fffff], 0x02982600 bytes flags: no-overwrite => efidebug memmap -- does not show regions allocated by lmb Missing TPMv2 device for EFI_TCG_PROTOCOL Type Start End Attributes ================ ================ ================ ========== CONVENTIONAL 0000000040000000-000000007f751000 WB BOOT DATA 000000007f751000-000000007f756000 WB RUNTIME DATA 000000007f756000-000000007f757000 WB|RT BOOT DATA 000000007f757000-000000007f758000 WB RUNTIME DATA 000000007f758000-000000007f77a000 WB|RT BOOT DATA 000000007f77a000-000000007f781000 WB BOOT CODE 000000007f781000-00000000807b5000 WB RUNTIME DATA 00000000807b5000-00000000807b6000 WB|RT BOOT CODE 00000000807b6000-00000000817c0000 WB RUNTIME CODE 00000000817c0000-00000000817d0000 WB|RT BOOT CODE 00000000817d0000-0000000082100000 WB => Trying to allocate EFI memory with already allocated region succeeds(should fail) --------------------------------------------------------------------------------- => efi_mem alloc 2000 42000000 Address returned 0x42000000 => efidebug memmap Type Start End Attributes ================ ================ ================ ========== CONVENTIONAL 0000000040000000-0000000042000000 WB BOOT DATA 0000000042000000-0000000042002000 WB CONVENTIONAL 0000000042002000-000000007f751000 WB BOOT DATA 000000007f751000-000000007f756000 WB RUNTIME DATA 000000007f756000-000000007f757000 WB|RT BOOT DATA 000000007f757000-000000007f758000 WB RUNTIME DATA 000000007f758000-000000007f77a000 WB|RT BOOT DATA 000000007f77a000-000000007f781000 WB BOOT CODE 000000007f781000-00000000807b5000 WB RUNTIME DATA 00000000807b5000-00000000807b6000 WB|RT BOOT CODE 00000000807b6000-00000000817c0000 WB RUNTIME CODE 00000000817c0000-00000000817d0000 WB|RT BOOT CODE 00000000817d0000-0000000082100000 WB => With patch series ----------------- lmb_dump_all: memory.count = 0x1 memory[0] [0x40000000-0x820fffff], 0x42100000 bytes flags: none reserved.count = 0x4 reserved[0] [0xe100000-0xeffffff], 0x00f00000 bytes flags: no-map reserved[1] [0x42000000-0x421fffff], 0x00200000 bytes flags: no-map reserved[2] [0x7f74f000-0x7f77dfff], 0x0002f000 bytes flags: no-notify, no-overwrite reserved[3] [0x7f77ea00-0x820fffff], 0x02981600 bytes flags: no-overwrite => efidebug memmap Type Start End Attributes ================ ================ ================ ========== BOOT DATA 000000000e100000-000000000f000000 WB CONVENTIONAL 0000000040000000-0000000042000000 WB BOOT DATA 0000000042000000-0000000042200000 WB CONVENTIONAL 0000000042200000-000000007f74e000 WB BOOT DATA 000000007f74e000-000000007f753000 WB RUNTIME DATA 000000007f753000-000000007f754000 WB|RT BOOT DATA 000000007f754000-000000007f755000 WB RUNTIME DATA 000000007f755000-000000007f777000 WB|RT BOOT DATA 000000007f777000-00000000807b6000 WB RUNTIME DATA 00000000807b6000-00000000807b7000 WB|RT BOOT DATA 00000000807b7000-00000000817c0000 WB RUNTIME CODE 00000000817c0000-00000000817d0000 WB|RT BOOT DATA 00000000817d0000-0000000082100000 WB Trying to allocate EFI memory with already allocated region fails ----------------------------------------------------------------- => efi_mem alloc 2000 42000000 efi_allocate_pages failed 800000000000000e => Trying to allocate EFI memory with non-allocated region succeeds ---------------------------------------------------------------- => efi_mem alloc 2000 42200000 Address returned 0x42200000 => efidebug memmap Type Start End Attributes ================ ================ ================ ========== BOOT DATA 000000000e100000-000000000f000000 WB CONVENTIONAL 0000000040000000-0000000042000000 WB BOOT DATA 0000000042000000-0000000042202000 WB CONVENTIONAL 0000000042202000-000000007f74d000 WB BOOT DATA 000000007f74d000-000000007f752000 WB RUNTIME DATA 000000007f752000-000000007f753000 WB|RT BOOT DATA 000000007f753000-000000007f754000 WB RUNTIME DATA 000000007f754000-000000007f776000 WB|RT BOOT DATA 000000007f776000-00000000807b5000 WB RUNTIME DATA 00000000807b5000-00000000807b6000 WB|RT BOOT DATA 00000000807b6000-00000000817c0000 WB RUNTIME CODE 00000000817c0000-00000000817d0000 WB|RT BOOT DATA 00000000817d0000-0000000082100000 WB => lmb_dump_all: memory.count = 0x1 memory[0] [0x40000000-0x820fffff], 0x42100000 bytes flags: none reserved.count = 0x5 reserved[0] [0xe100000-0xeffffff], 0x00f00000 bytes flags: no-map reserved[1] [0x42000000-0x421fffff], 0x00200000 bytes flags: no-map reserved[2] [0x42200000-0x42201fff], 0x00002000 bytes flags: no-notify, no-overwrite reserved[3] [0x7f74e000-0x7f77cfff], 0x0002f000 bytes flags: no-notify, no-overwrite reserved[4] [0x7f77da00-0x820fffff], 0x02982600 bytes flags: no-overwrite Link: https://lore.kernel.org/r/20241015153717.401371-1-sughosh.ganu@linaro.org
-
A bunch of static functions in the LMB module have used a double-undersore for the function names. It was suggested to use a single-underscore instead, as the double-underscore is usually used by library functions. Replace the double-underscore with single-underscore for all functions. Signed-off-by:
Sughosh Ganu <sughosh.ganu@linaro.org> Suggested-by:
-
The variable overlap_only_ram is used to specify that the new memory region that is being created needs to come from the free memory pool -- this is done by carving out the memory region from the free memory. The name is a bit confusing though, as other allocated memory regions, like boot-services code and data are also part of the RAM memory. Rename the variable to overlap_conventional to highlight the fact that it is the free/conventional memory that is being referred to in this context. Signed-off-by:
-
The EFI memory allocations are now being done through the LMB module. With this change, there is no need to get the EFI memory map and set aside EFI allocated memory. Signed-off-by:
-
The EFI_CONVENTIONAL_MEMORY type, which is the usable RAM memory is now being managed by the LMB module. Remove the addition of this memory type to the EFI memory map. This memory now gets added to the EFI memory map as part of the LMB memory map update event handler. Signed-off-by:
-
The EFI_CONVENTIONAL_MEMORY type is now being managed through the LMB module. Add a separate function, lmb_arch_add_memory() to add the RAM memory to the LMB memory map. The efi_add_known_memory() function is now used for adding any other memory type to the EFI memory map. Signed-off-by: -
The EFI memory allocations are now being done through the LMB module, and hence the memory map is maintained by the LMB module. Use the lmb_arch_add_memory() API function to add the usable RAM memory to the LMB's memory map. Signed-off-by: -
Some architectures have special or unique aspects which need consideration when adding memory ranges to the list of available memory map. Enable this config in such scenarios which allow architectures and boards to define their own memory map. Signed-off-by: -
The efi_add_known_memory() function for the stm32mp platforms is adding the EFI_CONVENTIONAL_MEMORY type. This memory is now being handled through the LMB module -- the lmb_add_memory() adds this memory to the memory map. Remove the definition of the now superfluous efi_add_known_memory() function. Signed-off-by:
-
The efi_add_known_memory() function for the TI K3 platforms is adding the EFI_CONVENTIONAL_MEMORY type. This memory is now being handled through the LMB module -- the lmb_add_memory() adds this memory to the memory map. Remove the definition of the now superfluous efi_add_known_memory() function. Signed-off-by:
-
The memory region occupied by U-Boot is reserved by LMB, and gets added to the EFI memory map through a call from the LMB module. Remove this superfluous addition to the EFI memory map. Signed-off-by:
-
In U-Boot, LMB and EFI are two primary modules who provide memory allocation and reservation API's. Both these modules operate with the same regions of memory for allocations. Use the LMB memory map update event to notify other interested listeners about a change in it's memory map. This can then be used by the other module to keep track of available and used memory. There is no need to send these notifications when the LMB module is being unit-tested. Add a flag to the lmb structure to indicate if the memory map is being used for tests, and suppress sending any notifications when running these unit tests. Signed-off-by: -
Use the LMB API's for allocating and freeing up memory. With this, the LMB module becomes the common backend for managing non U-Boot image memory that might be requested by other modules. Signed-off-by: -
U-Boot does not use memory above ram_top. However, this memory does need to get registered as part of the memory map, so that subsystems like EFI pass it on to the operating system as part of the EFI memory map. Add memory above ram_top and reserve it with the LMB_NOOVERWRITE flag so that it does not get allocated or re-used. Signed-off-by:
Mark Kettenis <kettenis@openbsd.org>
-
Add a flag LMB_NONOTIFY that can be passed to the LMB API's for reserving memory. This will then result in no notification being sent from the LMB module for the changes to the LMB's memory map. While here, also add a description of the memory attributes that the flags signify. Signed-off-by: -
The LMB module is to be used as a backend for allocating and freeing up memory requested from other modules like EFI. These memory requests are different from the typical LMB reservations in that memory required by the EFI module cannot be overwritten, or re-requested. Add versions of the LMB API functions with flags for allocating and freeing up memory. The caller can then use these API's for specifying the type of memory that is required. For now, these functions will be used by the EFI memory module. Signed-off-by:
-
A comment in test-main.c was not updated with the recent rename. Fix it. Signed-off-by:
Mattijs Korpershoek <mkorpershoek@baylibre.com>
-
The SPL_FIT_GENERATOR is long superseded by binman, drop SPL_FIT_GENERATOR support as there are no more users. Signed-off-by:
Marek Vasut <marex@denx.de> Reviewed-by:
Peter Robinson <pbrobinson@gmail.com> Reviewed-by:
-
The SPL_FIT_SOURCE is long superseded by SPL_FIT_GENERATOR which is long superseded by binman, drop SPL_FIT_SOURCE support as there are no more users. Signed-off-by:
-
When the config option CMD_MISC was renamed to CMD_SLEEP the check in the test for the sleep command was not updated. Do that now. Fixes: 16060854 ("cmd: Rename CMD_MISC to CMD_SLEEP") Signed-off-by:
Andrew Goodbody <andrew.goodbody@linaro.org> Reviewed-by:
-
Tom Rini authored
When we have platforms being emulated by QEMU we cannot rely on the "sleep" command running for the expected wall-clock amount of time. Even with our current allowance for deviation from expected time, it will still fail from time to time. Exclude the sleep test here. Signed-off-by:
-
