- Oct 17, 2024
-
-
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:
Marek Vasut <marex@denx.de> Reviewed-by:
Simon Glass <sjg@chromium.org> Reviewed-by:
Peter Robinson <pbrobinson@gmail.com>
-
https://source.denx.de/u-boot/custodians/u-boot-stmTom Rini authored
CI: https://source.denx.de/u-boot/custodians/u-boot-stm/-/pipelines/22732 - stm32mp: fix boot issue with OP-TEE - stm32mp: Add script to install U-Boot from SD/eMMC to SPI NOR on DH STM32MP15xx - stm32mp: Switch to using upstream DT on DH STM32 DHSOM - stm32mp: Generate u-boot.itb using binman on DH STM32 DHSOM
-
https://source.denx.de/u-boot/custodians/u-boot-dfuTom Rini authored
u-boot-dfu-20241017 CI: https://source.denx.de/u-boot/custodians/u-boot-dfu/-/pipelines/22742 Usb Gadget: - Fix cdns3 endpoint configuration by setting maxpacket - Fix dwc3 cache handling when using DMA Fastboot: - Make AVB_VERIFY depends on FASTBOOT
-
-
Add new section for USB TypeC Port Manager (TCPM) support, which is needed to figure out cable orientation of USB-C plus and to do USB PD communication. Signed-off-by:
Sebastian Reichel <sebastian.reichel@collabora.com> Acked-by:
-
Now that all code has been prepared update the default configuration to make use of it. Reviewed-by:
Kever Yang <kever.yang@rock-chips.com> Tested-by:
Soeren Moch <smoch@web.de> Tested-by:
Anand Moon <linux.amoon@gmail.com> Reviewed-by:
Jonas Karlman <jonas@kwiboo.se> Signed-off-by:
-
Add USB-C controller (fusb302), which will be used by U-Boot to initialize USB-PD. This is needed, because USB-PD communication must happen within 5 seconds after the USB-C connector got plugged. On my Rock 5B it often takes 5 seconds to jump to the Linux binary, so it must happen before Linux is initialized. This adds the DT node to the U-Boot specific file, since the Linux kernel DT currently does not describe it to avoid a system reset. The plan is to add it to the Linux DT with status = 'fail' and then let U-Boot mark it as status = 'okay' if it properly dealt with early USB-PD initialization. Until the Kernel DT has the node, let's add it in U-Boot to get things going. Reviewed-by:
-
Since older U-Boot releases do not negotiate USB PD, the kernel DT may not enable the USB-C controller by default to avoid a regression. The plan is to upstream it with 'status = "fail";' instead. U-Boot should then mark it as 'status = "okay";' if it negotiated USB PD. Currently existing upstream kernel DTs do not yet have the USB-C controller at all, so we ignore any failures. Reviewed-by:
-
Now that the TCPM framework exists we can introduce fusb302 driver using it. This chip is a very common USB-C controller chip with PD support, which can be found in the Radxa Rock 5B among many other boards. Apart from Power Delivery, it also handles detection of the cable orientation. That can be used to control a mux for connecting the right USB3 lane pair to the USB3 controller. The driver is originally from the Linux kernel, but has been adapted to the requirements of U-Boot and its TCPM framework. Co-developed-by:
Wang Jie <dave.wang@rock-chips.com> Signed-off-by:
-
This adds TCPM framework in preparation for fusb302 support, which can handle USB power delivery messages. This is needed to solve issues with devices, that are running from a USB-C port supporting USB-PD, but not having a battery. Such a device currently boots to the kernel without interacting with the power-supply at all. If there are no USB-PD message replies within 5 seconds, the power-supply assumes the peripheral is not capable of USB-PD. It usually takes more than 5 seconds for the system to reach the kernel and probe the I2C based fusb302 chip driver. Thus the system always runs into this state. The power-supply's solution to fix this error state is a hard reset, which involves removing the power from VBUS. Boards without a battery (or huge capacitors) will reset at this point resulting in a boot loop. This imports the TCPM framework from the kernel. The porting has originally been done by Rockchip using hardware timers and the Linux kernel's TCPM code from some years ago. I had a look at upgrading to the latest TCPM kernel code, but that beast became a lot more complex due to adding more USB-C features. I believe these features are not needed in U-Boot and with multiple kthreads and hrtimers being involved it is non-trivial to port them. Instead I worked on stripping down features from the Rockchip port to an even more basic level. Also the TCPM code has been reworked to avoid complete use of any timers (Rockchip used SoC specific hardware timers + IRQ to implement delayed work mechanism). Instead the delayed state changes are handled directly from the poll loop. Note, that (in contrast to the original Rockchip port) the state machine has the same hard reset quirk, that the kernel has - i.e. it avoids disabling the CC pin resistors for devices that are not self-powered. Without that quirk, the Radxa Rock 5B will not just end up doing a machine reset when a hard reset is triggered, but will not even recover, because the CPU will loose power and the FUSB302 will keep this state because of leak voltage arriving through the RX serial pin (assuming a serial adapter is connected). This also includes a 'tcpm' command, which can be used to get information about the current state and the negotiated voltage and current. Co-developed-by:
-
- Oct 16, 2024
-
-
Tom Rini authored
Rasmus Villemoes <ravi@prevas.dk> says: Some small improvements to the serial rx buffer feature. CI seems happy: https://github.com/u-boot/u-boot/pull/674 Link: https://lore.kernel.org/r/20241003141029.920035-1-ravi@prevas.dk
-
The initialization of upriv->buf doesn't check for a NULL return. But there's actually no point in doing a separate, unconditional malloc() in post_probe; we can just make serial_dev_priv contain the rx buffer itself, and let the (larger) allocation be handled by the driver core when it allocates the ->per_device_auto. The total run-time memory used is mostly the same, we reduce the code size a little, and as a bonus, struct serial_dev_priv does not contain the unused members when !SERIAL_RX_BUFFER. Signed-off-by:
Rasmus Villemoes <ravi@prevas.dk> Reviewed-by:
-
The help text says it must be a power of 2, and the implementation does rely on that. Enforce it. A violation gives a wall of text, but the last few lines should be reasonably obvious: drivers/serial/serial-uclass.c:334:9: note: in expansion of macro ‘BUILD_BUG_ON_NOT_POWER_OF_2’ 334 | BUILD_BUG_ON_NOT_POWER_OF_2(CONFIG_SERIAL_RX_BUFFER_SIZE); Signed-off-by:
-
Before the previous patch, pasting a string of length x > CONFIG_SERIAL_RX_BUFFER_SIZE results in getting the last (x%CONFIG_SERIAL_RX_BUFFER_SIZE) characters from that string. With the previous patch, one instead gets the last CONFIG_SERIAL_RX_BUFFER_SIZE characters repeatedly until the ->rd_ptr catches up. Both behaviours are counter-intuitive, and happen because the code that checks for a character available from the hardware does not account for whether there is actually room in the software buffer to receive it. Fix that by adding such accounting. This also brings the software buffering more in line with how most hardware FIFOs behave (first received characters are kept, overflowing characters are dropped). Signed-off-by:
-
The current implementation of the circular rx buffer falls into a common trap with circular buffers: It keeps the head/tail indices reduced modulo the buffer size. The problem with that is that it makes it impossible to distinguish "buffer full" from "buffer empty", because in both situations one has head==tail. This can easily be demonstrated: Build sandbox with RX_BUFFER enabled, set the RX_BUFFER_SIZE to 32, and try pasting the string 01234567890123456789012345678901 Nothing seems to happen, but in reality, all characters have been read and put into the buffer, but then tstc ends up believing nothing is in the buffer anyway because upriv->rd_ptr == upriv->wr_ptr. A better approach is to let the indices be free-running, and only reduce them modulo the buffer size when accessing the array. Then "empty" is head-tail==0 and "full" is head-tail==size. This does rely on the buffer size being a power-of-two and the free-running indices simply wrapping around to 0 when incremented beyond the maximal positive value. Incidentally, that change from signed to unsigned int also improves code generation quite a bit: In C, (signed int)%(signed int) is defined to have the sign of the dividend (so (-35) % 32 is -3, not 29), and hence despite the modulus being a power-of-two, x % 32 does not actually compile to the same as a simple x & 31 - on x86 with -Os, it seems that gcc ends up emitting an idiv instruction, which is quite expensive. Signed-off-by:
-
Patrick Delaunay authoredThis is cosmetic change. Remove the empty comment blocks remaining after conversion to Kconfig of CONFIG_SYS_MAX_NAND_DEVICE and CONFIG_SERVERIP. Signed-off-by:
Patrick Delaunay <patrick.delaunay@foss.st.com> -
Make the dh_update_sd_to_sf script generic, rename it to dh_update_block_to_sf and implement two specific dh_update_sd_to_sf and dh_update_emmc_to_sf scripts which load U-Boot from either SD or eMMC and install it into SPI NOR. Signed-off-by:
Patrick Delaunay <patrick.delaunay@foss.st.com> -
Patrick Delaunay authored
In OP-TEE, the "optee_core@" node is reserved, appended in non secure device tree (see mark_tzdram_as_reserved() function under CFG_DT) so this name must be checked in optee_get_reserved_memory(). We keep the check on /reserved-memory/optee@ node to have backward compatibility with STMT32Image booting, when the reserved node is already present in U-Boot or SPL device tree with name "optee@". This patch solves a boot issue on board with OP-TEE for U-Boot compiled with stm32mp15_defconfig and without secure configuration device tree (stm32mp157c-dk2.dts for example). Fixes: 5fe9e0de ("stm32mp: allow calling optee_get_reserved_memory() from U-Boot") Signed-off-by:
Patrick Delaunay <patrick.delaunay@foss.st.com> -
Patrick Delaunay authored
Clarify the usage of SCMI specific device tree to use with stm32mp15_defconfig and with OP-TEE. Signed-off-by:Patrick Delaunay <patrick.delaunay@foss.st.com> -
Patrick Delaunay authored
Move the stm32mp1 data cache reconfiguration after the lmb init call board_r::initr_lmb to allow parsing of the reserved region with no-map tag. After this patch the DDR is not fully mapped up to arch_early_init_r() call, only the relocation region is mapped, but it is enough for the first board_r initialization phases; later, when arch_early_init_r() is called, the LMB is already initialized and the function lmb_is_reserved_flags() function is functional, this LMB function is called in the weak function dram_bank_mmu_setup() when dcache_enable() is executed. Without this change, as LMB is not initialized when it is used in dram_bank_mmu_setup, the OP-TEE region is mapped cache-able by U-Boot and we have some firewall violation since "LMB memory map global and persistent" series. Fixes: ed17a33f ("lmb: make LMB memory map persistent and global") Signed-off-by:
Patrick Delaunay <patrick.delaunay@foss.st.com> -
Patrick Delaunay authored
Reserved memory for OP-TEE is located at end of DDR for STM32MP1 SoC only (STM32MP13 and STM32MP15) and the OP-TEE reserved memory is located at the beginning of DDR for STM32MP25 SoC, before CONFIG_TEXT_BASE and with reserved memory for companion coprocessor. So the ram_top is limited by OP-TEE reserved memory only for STM32MP1 SoC. This patch solves an issue for ram_top value on STM32MP25 SoC because the generic reserved memory management, based on LMB, is no more used before relocation. Fixes: 8242f14a ("stm32mp: compute ram_top based on the optee base address") Signed-off-by:
Patrick Delaunay <patrick.delaunay@foss.st.com> -
Describe the u-boot.its generation in stm32mp15xx-dhsom-u-boot.dtsi binman {} DT node as a replacement for current CONFIG_SPL_FIT_SOURCE use, dispose of both u-boot-dhcom.its and u-boot-dhcor.its. Use fdt-SEQ/config-SEQ to generate a list of fdt-N fitImage images {} and matching configuration {} node entries. The configuration node entry names no longer encode _somrevN_boardrevN suffix, which was never really used, so drop this functionality by default. Rework board_fit_config_name_match() to match on the new configuration node entry names. Users who do need the match on _somrevN_boardrevN can either replace the fdt-SEQ/config-SEQ with fixed fdt-N/config-N nodes which each encode the matching 'description = "NAME_somrevN_boardrevN"' to restore the old behavior verbatim, or better use SPL DT overlays for U-Boot control DT the same way e.g. i.MX8MP DHCOM does to support multiple SoM and board variants. Signed-off-by:Patrick Delaunay <patrick.delaunay@foss.st.com> -
Enable OF_UPSTREAM to use upstream DT and add st/ prefix to the DEFAULT_DEVICE_TREE. And thereby directly build DTB from dts/upstream/src/ including *-u-boot.dtsi from arch/$(ARCH)/dts/ directory. The previous setup used generic SoC prefix like stm32mp15xx-dhco* for generic DTs which could be used on any STM32MP15xx DHSOM variant. The new setup uses specific SoC prefix stm32mp157c-dhco* to match Linux DT names. Since the hardware present on STM32MP153 and STM32MP157 is not enabled in the board configuration and not supported by U-Boot except for the DSI host, using the existing Linux DTs poses no issue even on plain STM32MP151A based SoMs. Signed-off-by:
Patrick Delaunay <patrick.delaunay@foss.st.com> -
The cpu0-opp-table {} node does not exist in upstream Linux stm32mp151.dtsi file, in order to enable conversion to OF_UPSTREAM, duplicate the node from current U-Boot stm32mp151.dtsi into stm32mp15-u-boot.dtsi. This makes STM32 DTs buildable even with OF_UPSTREAM enabled. No functional change, since the current U-Boot stm32mp151.dtsi already contains the cpu0-opp-table {} node, stm32mp15-u-boot.dtsi is applied at the end, and does not bring in any new content. Signed-off-by:Patrick Delaunay <patrick.delaunay@foss.st.com> -
Update the MAINTAINERS file glob to cover all of STM32MP DHSOM related files. Signed-off-by:
Tom Rini <trini@konsulko.com> Reviewed-by:
Patrick Delaunay <patrick.delaunay@foss.st.com> -
Tom Rini authored
Jerome Forissier <jerome.forissier@linaro.org> says: This is a rework of a patch series by Maxim Uvarov: "net/lwip: add lwip library for the network stack" [1]. The goal is to introduce the lwIP TCP/IP stack [2] [3] as an alternative to the current implementation in net/, selectable with Kconfig, and ultimately keep only lwIP if possible. Some reasons for doing so are: - Make the support of HTTPS in the wget command easier. Javier T. and Raymond M. (CC'd) have some additional lwIP and Mbed TLS patches to do so. With that it becomes possible to fetch and launch a distro installer such as Debian etc. using a secure, authenticated connection directly from the U-Boot shell. Several use cases: * Authentication: prevent MITM attack (third party replacing the binary with a different one) * Confidentiality: prevent third parties from grabbing a copy of the image as it is being downloaded * Allow connection to servers that do not support plain HTTP anymore (this is becoming more and more common on the Internet these days) - Possibly benefit from additional features implemented in lwIP - Less code to maintain in U-Boot Prior to applying this 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 Notes 1. A number of features are currently incompatible with NET_LWIP: DFU_TFTP, FASTBOOT, SPL_NET, ETH_SANDBOX, ETH_SANDBOX_RAW, DM_ETH. They all make assumptions on how the network stack is implemented and/or pull sybols that are not trivially exported from lwIP. Some interface rework may be needed. 2. Due to the above, and in order to provide some level of testing of the lwIP code in CI even when the legacy NET is the default, a new QEMU configuration is introduced (qemu_arm64_lwip_defconfig) which is based on qemu_arm64_defconfig with NET_LWIP and CMD_*_LWIP enabled. In addition to that, this series has some [TESTING] patches which make NET_LWIP the default. [1] https://lore.kernel.org/all/20231127125726.3735-1-maxim.uvarov@linaro.org/ [2] https://www.nongnu.org/lwip/ [3] https://en.wikipedia.org/wiki/LwIP Link: https://lore.kernel.org/r/cover.1729070678.git.jerome.forissier@linaro.org
-
Add myself as a maintainer for the lwIP network stack integration code and network commands as well as the sandbox ethernet driver for lwIP. Signed-off-by:
Jerome Forissier <jerome.forissier@linaro.org> Acked-by:
Ilias Apalodimas <ilias.apalodimas@linaro.org>
-
Build and run qemu_arm64_lwip_defconfig in CI. This tests the lightweight IP (lwIP) implementation of the dhcp, tftpboot and ping commands. Signed-off-by: -
Add support for setting the TFTP block size. The default value (1468) is fine for Ethernet and allows a better throughput than the TFTP default (512), if the server supports the blksize option of course. I tested this change with qemu_arm64_lwip_defconfig. The throughput is now 875 KiB/s vs. 313 KiB/s before. That is still a low number, but I think we can't expect more without implementing the windowsize option. Signed-off-by:
-
The TFTP protocol uses a default block size of 512 bytes. This value is sub-optimal for ethernet devices, which have a MTU (Maximum Transmission Unit) of 1500 bytes. When taking into acount the overhead of the IP and UDP layers, this leaves 1468 bytes for the TFTP payload. This patch introduces a new function: tftp_client_set_blksize() which may be used to change the block size from the default. It has to be called after tftp_client_init() and before tftp_get(). If the server does not support the option, the client will still accept to receive 512-byte blocks. Submitted upstream: https://savannah.nongnu.org/patch/index.php?10462 Signed-off-by:
-
Add qemu_arm64_lwip_defconfig which #include's qemu_arm64_defconfig and selects NET_LWIP instead of NET. This config has all the supported net commands enabled. Signed-off-by:
-
Support "bdinfo -e" when lwIP is selected. Signed-off-by:
-
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:Maxim Uvarov <muvarov@gmail.com> Cc: Maxim Uvarov <muvarov@gmail.com> Signed-off-by:
-
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:
-
