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: Marek Vasut <marex@denx.de>
rockchip: rk3588-rock-5b: Add USB-C controller to u-boot.dtsi
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: 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: Sebastian Reichel <sebastian.reichel@collabora.com>
board: rock5b-rk3588: enable USB-C in operating system
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: 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: Sebastian Reichel <sebastian.reichel@collabora.com>
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: Wang Jie <dave.wang@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: Sebastian Reichel <sebastian.reichel@collabora.com>
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: Wang Jie <dave.wang@rock-chips.com> Signed-off-by: Wang Jie <dave.wang@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: Sebastian Reichel <sebastian.reichel@collabora.com>
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:
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.
Jerome Forissier [Wed, 16 Oct 2024 10:04:13 +0000 (12:04 +0200)]
net: lwip: add TFTP_BLOCKSIZE
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.
Jerome Forissier [Wed, 16 Oct 2024 10:04:12 +0000 (12:04 +0200)]
net: lwip: tftp: add support of blksize option to client
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.
Jerome Forissier [Wed, 16 Oct 2024 10:04:11 +0000 (12:04 +0200)]
configs: add qemu_arm64_lwip_defconfig
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.
Jerome Forissier [Wed, 16 Oct 2024 10:04:09 +0000 (12:04 +0200)]
net: lwip: add wget command
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}.
Jerome Forissier [Wed, 16 Oct 2024 10:04:04 +0000 (12:04 +0200)]
net: lwip: tftp: bind to TFTP port only when in server mode
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).
Jerome Forissier [Wed, 16 Oct 2024 10:04:03 +0000 (12:04 +0200)]
net: lwip: add DHCP support and dhcp commmand
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.
Jerome Forissier [Wed, 16 Oct 2024 10:04:00 +0000 (12:04 +0200)]
net: split net into net{,-common,-legacy,-lwip}
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.
Jerome Forissier [Wed, 16 Oct 2024 10:03:59 +0000 (12:03 +0200)]
net: introduce alternative implementation as net/lwip/
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.
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: Jerome Forissier <jerome.forissier@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org>
Jerome Forissier [Wed, 16 Oct 2024 09:56:24 +0000 (11:56 +0200)]
sandbox: add dummy driver ETH_SANDBOX_LWIP
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.
Jerome Forissier [Wed, 16 Oct 2024 09:56:23 +0000 (11:56 +0200)]
configs: use syntax CONFIG_FOO=n in tools-only_defconfig
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].
Tom Rini [Tue, 15 Oct 2024 19:46:08 +0000 (13:46 -0600)]
Merge patch series "Make EFI memory allocations synchronous with LMB"
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.
Trying to allocate EFI memory with already allocated region succeeds(should fail)
---------------------------------------------------------------------------------
=> efi_mem alloc 2000 42000000
Address returned 0x42000000
Sughosh Ganu [Tue, 15 Oct 2024 15:37:17 +0000 (21:07 +0530)]
lmb: replace the double-underscore with single-underscore for all functions
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: Simon Glass <sjg@chromium.org>
Sughosh Ganu [Tue, 15 Oct 2024 15:37:16 +0000 (21:07 +0530)]
efi_memory: rename variable to highlight overlap with free memory
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.
Sughosh Ganu [Tue, 15 Oct 2024 15:37:15 +0000 (21:07 +0530)]
lmb: remove call to efi_lmb_reserve()
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.
Sughosh Ganu [Tue, 15 Oct 2024 15:37:14 +0000 (21:07 +0530)]
efi_memory: do not add RAM memory to the memory map
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.
Sughosh Ganu [Tue, 15 Oct 2024 15:37:13 +0000 (21:07 +0530)]
x86: e820: use the lmb API for adding RAM memory
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.
Sughosh Ganu [Tue, 15 Oct 2024 15:37:12 +0000 (21:07 +0530)]
layerscape: use the lmb API's to add RAM memory
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.
Sughosh Ganu [Tue, 15 Oct 2024 15:37:11 +0000 (21:07 +0530)]
lmb: allow for boards to specify memory map
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.
Sughosh Ganu [Tue, 15 Oct 2024 15:37:10 +0000 (21:07 +0530)]
stm32mp: remove efi_add_known_memory() function definition
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.
Sughosh Ganu [Tue, 15 Oct 2024 15:37:09 +0000 (21:07 +0530)]
ti: k3: remove efi_add_known_memory() function definition
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.
Sughosh Ganu [Tue, 15 Oct 2024 15:37:08 +0000 (21:07 +0530)]
efi_memory: do not add U-Boot memory to the memory map
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.
Sughosh Ganu [Tue, 15 Oct 2024 15:37:07 +0000 (21:07 +0530)]
lmb: notify of any changes to the LMB memory map
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.
Sughosh Ganu [Tue, 15 Oct 2024 15:37:06 +0000 (21:07 +0530)]
efi: memory: use the lmb API's for allocating and freeing memory
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.
Sughosh Ganu [Tue, 15 Oct 2024 15:37:05 +0000 (21:07 +0530)]
lmb: add and reserve memory above ram_top
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: Sughosh Ganu <sughosh.ganu@linaro.org> Suggested-by: Mark Kettenis <kettenis@openbsd.org>
Sughosh Ganu [Tue, 15 Oct 2024 15:37:04 +0000 (21:07 +0530)]
lmb: add a flag to allow suppressing memory map change notification
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.
Sughosh Ganu [Tue, 15 Oct 2024 15:37:03 +0000 (21:07 +0530)]
lmb: add versions of the lmb API with flags
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: Sughosh Ganu <sughosh.ganu@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org>
Andrew Goodbody [Tue, 8 Oct 2024 12:08:13 +0000 (13:08 +0100)]
test: Fix skip check for sleep command test
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: 16060854095 ("cmd: Rename CMD_MISC to CMD_SLEEP") Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org>
Tom Rini [Tue, 15 Oct 2024 18:28:26 +0000 (12:28 -0600)]
CI: Do not test "sleep" in QEMU
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.
Jonas Karlman [Tue, 8 Oct 2024 19:18:31 +0000 (19:18 +0000)]
Revert "mmc: dw_mmc: Extract FIFO data transfer into a separate routine"
The commit 0252924ac6d4 ("mmc: dw_mmc: Extract FIFO data transfer into a
separate routine") unintentionally changed behavior of the FIFO data
transfer routine.
When data is read and size reaches 0 the original loop would wait on
DWMCI_INTMSK_DTO or timeout. The remaining size to read and buf position
is no longer tracked across dwmci_data_transfer_fifo() calls and because
of this an extra call to fifo() and dwmci_fifo_ready() may now trigger a
FIFO underflow timeout error and slows down FIFO reading.
Fixes: 0252924ac6d4 ("mmc: dw_mmc: Extract FIFO data transfer into a separate routine") Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Tested-by: Quentin Schulz <quentin.schulz@cherry.de> # RK3588 Tiger Reviewed-by: Simon Glass <sjg@chromium.org>
Tom Rini [Tue, 15 Oct 2024 15:31:50 +0000 (09:31 -0600)]
Merge patch series "test: Minor fixes to test.py"
Simon Glass <sjg@chromium.org> says:
This series collects together the patches from the Labgrid series which
are not related to Labgrid, or at least can be applied independently of
using Labgrid to run the lab.
Tom Rini [Tue, 15 Oct 2024 15:18:04 +0000 (09:18 -0600)]
Merge patch series to add a "fallback" keyword to extlinux.conf parsing
This series from Martyn Welch <martyn.welch@collabora.com> adds the
ability to have a "fallback" option in extlinux.conf parsing, which can
be in turn used in A/B style update mechanisms.
Martyn Welch [Wed, 9 Oct 2024 13:15:40 +0000 (14:15 +0100)]
bootstd: Add command to enable setting of bootmeth specific properties
We have previously added logic to allow a "fallback" option to be
specified in the extlinux configuration. Provide a command that allows
us to set this as the preferred default option when booting.
Combined with the bootcount functionality, this allows the "altbootcmd"
to provide a means of falling back to a previously known good state
after a failed update. For example, if "bootcmd" is set to:
bootflow scan -lb
We would set "altbootcmd" to:
bootmeth set extlinux fallback 1; bootflow scan -lb
Causing the boot process to boot from the fallback option.
Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Martyn Welch <martyn.welch@collabora.com>
Martyn Welch [Wed, 9 Oct 2024 13:15:39 +0000 (14:15 +0100)]
boot: Add logic to enable booting from fallback option
The "fallback" extlinux config option allows us to set an alternative
default boot option for when it has been detected that the default is
failing. Implement the logic required to boot from this option when
desired.
Signed-off-by: Martyn Welch <martyn.welch@collabora.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Simon Glass [Thu, 10 Oct 2024 00:29:03 +0000 (18:29 -0600)]
test: Detect dead connections
When the connection to a board dies, assume it is dead forever until
some user action is taken. Skip all remaining tests. This avoids CI
runs taking an hour, with hundreds of 30-second timeouts all to no
avail.
Martyn Welch [Wed, 9 Oct 2024 13:15:38 +0000 (14:15 +0100)]
boot: pxe_utils: Add fallback support
When configured correctly, we can detect when boot fails after the boot
process has been handed over to the kernel through the use of U-Boot's
bootcount support. In some instances, such as when we are performing
atomic updates via a system such as OSTree, it is desirable to provide a
fallback option so that we can return to a previous (hopefully working)
state.
Add a "fallback" option to the supported extlinux configuration options
that points to a label like "default" so that we can utilise this in
later commits.
Signed-off-by: Martyn Welch <martyn.welch@collabora.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Simon Glass [Thu, 10 Oct 2024 00:29:02 +0000 (18:29 -0600)]
test: Separate out the exception handling
The tests currently catch a very broad Exception in each case. This is
thrown even in the event of a coding error.
We want to handle exceptions differently depending on their severity,
so that we can avoid hour-long delays waiting for a board that is
clearly broken.
As a first step, create some new exception types, separating out those
which are simply an unexpected result from executed a command, from
those which indicate some kind of hardware failure.
Simon Glass [Thu, 10 Oct 2024 00:28:59 +0000 (18:28 -0600)]
test: Avoid failing skipped tests
When a test returns -EAGAIN this should not be considered a failure.
Fix what seems to be a problem case, where the pytests see a failure
when a test has merely been skipped.
We cannot squash the -EAGAIN error in ut_run_test() since the failure
count is incremented by its caller, ut_run_test_live_flat()
The specific example here is on snow, where a test is compiled into the
image but cannot run, so returns -EAGAIN to skip:
Changes in v2:
- Fix an issue in setting macronix_octal_fixups
- Rework fixup hooks
Takahiro Kuwano (6):
mtd: ubi: Do not zero out EC and VID on ECC-ed NOR flashes
mtd: spi-nor: Allow flashes to specify MTD writesize
mtd: spi-nor: Check nor->info before setting macronix_octal_fixups
mtd: spi-nor: Replace default_init() hook with late_init()
mtd: spi-nor: Call spi_nor_post_sfdp_fixups() only after
spi_nor_parse_sfdp()
mtd: spi-nor: Set ECC unit size to MTD writesize in Infineon SEMPER
flashes
Takahiro Kuwano [Tue, 15 Oct 2024 04:08:36 +0000 (13:08 +0900)]
mtd: spi-nor: Set ECC unit size to MTD writesize in Infineon SEMPER flashes
The Infineon SEMPER NOR flash family uses 2-bit ECC by default with each
ECC block being 16 bytes. Under this scheme multi-pass programming to an
ECC block is not allowed. Set the writesize to make sure multi-pass
programming is not attempted on the flash.
Takahiro Kuwano [Tue, 15 Oct 2024 04:08:35 +0000 (13:08 +0900)]
mtd: spi-nor: Call spi_nor_post_sfdp_fixups() only after spi_nor_parse_sfdp()
This patch follows the upstream linux commit: 5273cc6df984("mtd: spi-nor: core: Call spi_nor_post_sfdp_fixups() only
when SFDP is defined")
spi_nor_post_sfdp_fixups() was called regardless of if
spi_nor_parse_sfdp() had been called or not. late_init() should be
instead used to initialize the parameters that are not defined in SFDP.
Ideally spi_nor_post_sfdp_fixups() is called only after successful parse
of SFDP. However, in case SFDP support is disabled by .config, that can
break current functionality. Therefore, we would call it after
spi_nor_parse_sfdp() regardless of its return value.
Takahiro Kuwano [Tue, 15 Oct 2024 04:08:34 +0000 (13:08 +0900)]
mtd: spi-nor: Replace default_init() hook with late_init()
default_init() is wrong, it contributes to the maze of initializing
flash parameters. We'd like to get rid of it because the flash
parameters that it initializes are not really used at SFDP parsing time,
thus they can be initialized later.
Ideally we want SFDP to initialize all the flash parameters. If (when)
SFDP tables are wrong, we fix them with the post_sfdp/bfpt hooks, to
emphasize that SFDP is indeed wrong. When there are parameters that are
not covered by SFDP, we initialize them in late_init() - these
parameters have nothing to do with SFDP and they are not needed earlier.
With this we'll have a clearer view of who initializes what.
There are six default_init() hooks implemented just for initializing
octal_dtr_enable() and/or setup() hooks that called later on.
Just moving those to late_init() does not change functionality.
Takahiro Kuwano [Tue, 15 Oct 2024 04:08:32 +0000 (13:08 +0900)]
mtd: spi-nor: Allow flashes to specify MTD writesize
Some flashes like the Infineon SEMPER NOR flash family use ECC. Under
this ECC scheme, multi-pass writes to an ECC block is not allowed.
In other words, once data is programmed to an ECC block, it can't be
programmed again without erasing it first.
Upper layers like file systems need to be given this information so they
do not cause error conditions on the flash by attempting multi-pass
programming. This can be done by setting 'writesize' in 'struct
mtd_info'.
Set the default to 1 but allow flashes to modify it in fixup hooks. If
more flashes show up with this constraint in the future it might be
worth it to add it to 'struct flash_info', but for now increasing its
size is not worth it.
This patch replicates the following upstream linux commit: afd473e85827 ("mtd: spi-nor: core: Allow flashes to specify MTD writesize")
Takahiro Kuwano [Tue, 15 Oct 2024 04:08:31 +0000 (13:08 +0900)]
mtd: ubi: Do not zero out EC and VID on ECC-ed NOR flashes
For NOR flashes EC and VID are zeroed out before an erase is issued to
make sure UBI does not mistakenly treat the PEB as used and associate it
with an LEB.
But on some flashes, like the Infineon Semper NOR flash family,
multi-pass page programming is not allowed on the default ECC scheme.
This means zeroing out these magic numbers will result in the flash
throwing a page programming error.
Do not zero out EC and VID for such flashes. A writesize > 1 is an
indication of an ECC-ed flash.
This patch replicates the following upstream linux commit: f669e74be820 ("ubi: Do not zero out EC and VID on ECC-ed NOR flashes")
Marek Vasut [Fri, 4 Oct 2024 00:10:42 +0000 (02:10 +0200)]
dts: Deduplicate dtbs target
The dtbs: target is almost identical in all architecture Makefiles.
All architecture Makefiles include scripts/Makefile.dts . Deduplicate
the dtbs: target into scripts/Makefile.dts . No functional change.
Reviewed-by: Sumit Garg <sumit.garg@linaro.org> Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Caleb Connolly <caleb.connolly@linaro.org> #qcom, OF_UPSTREAM
Tom Rini [Mon, 14 Oct 2024 19:34:06 +0000 (13:34 -0600)]
Merge patch series "Integrate MbedTLS v3.6 LTS with U-Boot"
Raymond Mao <raymond.mao@linaro.org> says:
Integrate MbedTLS v3.6 LTS (currently v3.6.0) with U-Boot.
Motivations:
------------
1. MbedTLS is well maintained with LTS versions.
2. LWIP is integrated with MbedTLS and easily to enable HTTPS.
3. MbedTLS recently switched license back to GPLv2.
Prerequisite:
-------------
This patch series requires mbedtls git repo to be added as a
subtree to the main U-Boot repo via:
$ git subtree add --prefix lib/mbedtls/external/mbedtls \
https://github.com/Mbed-TLS/mbedtls.git \
v3.6.0 --squash
Moreover, due to the Windows-style files from mbedtls git repo,
we need to convert the CRLF endings to LF and do a commit manually:
$ git add --renormalize .
$ git commit
New Kconfig options:
--------------------
`MBEDTLS_LIB` is for MbedTLS general switch.
`MBEDTLS_LIB_CRYPTO` is for replacing original digest and crypto libs with
MbedTLS.
`MBEDTLS_LIB_CRYPTO_ALT` is for using original U-Boot crypto libs as
MbedTLS crypto alternatives.
`MBEDTLS_LIB_X509` is for replacing original X509, PKCS7, MSCode, ASN1,
and Pubkey parser with MbedTLS.
By default `MBEDTLS_LIB_CRYPTO_ALT` and `MBEDTLS_LIB_X509` are selected
when `MBEDTLS_LIB` is enabled.
`LEGACY_CRYPTO` is introduced as a main switch for legacy crypto library.
`LEGACY_CRYPTO_BASIC` is for the basic crypto functionalities and
`LEGACY_CRYPTO_CERT` is for the certificate related functionalities.
For each of the algorithm, a pair of `<alg>_LEGACY` and `<alg>_MBEDTLS`
Kconfig options are introduced. Meanwhile, `SPL_` Kconfig options are
introduced.
In this patch set, MBEDTLS_LIB, MBEDTLS_LIB_CRYPTO and MBEDTLS_LIB_X509
are by default enabled in qemu_arm64_defconfig and sandbox_defconfig
for testing purpose.
Patches for external MbedTLS project:
-------------------------------------
Since U-Boot uses Microsoft Authentication Code to verify PE/COFFs
executables which is not supported by MbedTLS at the moment,
addtional patches for MbedTLS are created to adapt with the EFI loader:
1. Decoding of Microsoft Authentication Code.
2. Decoding of PKCS#9 Authenticate Attributes.
3. Extending MbedTLS PKCS#7 lib to support multiple signer's certificates.
4. MbedTLS native test suites for PKCS#7 signer's info.
All above 4 patches (tagged with `mbedtls/external`) are submitted to
MbedTLS project and being reviewed, eventually they should be part of
MbedTLS LTS release.
But before that, please merge them into U-Boot, otherwise the building
will be broken when MBEDTLS_LIB_X509 is enabled.
See below PR link for the reference:
https://github.com/Mbed-TLS/mbedtls/pull/9001
Miscellaneous:
--------------
Optimized MbedTLS library size by tailoring the config file
and disabling all unnecessary features for EFI loader.
From v2, original libs (rsa, asn1_decoder, rsa_helper, md5, sha1, sha256,
sha512) are completely replaced when MbedTLS is enabled.
From v3, the size-growth is slightly reduced by refactoring Hash functions.
From v6, smaller implementations for SHA256 and SHA512 are enabled and
target size reduce significantly.
Target(QEMU arm64) size-growth when enabling MbedTLS:
v1: 6.03%
v2: 4.66%
v3 - v5: 4.55%
v6: 2.90%
Tests done:
-----------
EFI Secure Boot test (EFI variables loading and verifying, EFI signed image
verifying and booting) via U-Boot console.
EFI Secure Boot and Capsule sandbox test passed.
Raymond Mao [Thu, 3 Oct 2024 21:50:38 +0000 (14:50 -0700)]
asn1_decoder: add build options for ASN1 decoder
When building with MbedTLS, we are using MbedTLS to decode ASN1 data
for x509, pkcs7 and mscode.
Introduce _LEGACY and _MBEDTLS kconfigs for ASN1 decoder legacy and
MbedTLS implementations respectively.
Signed-off-by: Raymond Mao <raymond.mao@linaro.org> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Raymond Mao [Thu, 3 Oct 2024 21:50:36 +0000 (14:50 -0700)]
mbedtls: add RSA helper layer on MbedTLS
Add RSA helper layer on top on MbedTLS PK and RSA library.
Introduce _LEGACY and _MBEDTLS kconfigs for RSA helper legacy and
MbedTLS implementations respectively.
Signed-off-by: Raymond Mao <raymond.mao@linaro.org> Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Raymond Mao [Thu, 3 Oct 2024 21:50:35 +0000 (14:50 -0700)]
lib/crypto: Adapt mscode_parser to MbedTLS
Previous patch has introduced MbedTLS porting layer for mscode parser,
here to adjust the header and makefiles accordingly.
Adding _LEGACY Kconfig for legacy mscode implementation.
Signed-off-by: Raymond Mao <raymond.mao@linaro.org>
Raymond Mao [Thu, 3 Oct 2024 21:50:32 +0000 (14:50 -0700)]
mbedtls: add PKCS7 parser porting layer
Add porting layer for PKCS7 parser on top of MbedTLS PKCS7 library.
Introduce _LEGACY and _MBEDTLS kconfigs for PKCS7 parser legacy and
MbedTLS implementations respectively.
Signed-off-by: Raymond Mao <raymond.mao@linaro.org> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Raymond Mao [Thu, 3 Oct 2024 21:50:30 +0000 (14:50 -0700)]
mbedtls: add X509 cert parser porting layer
Add porting layer for X509 cert parser on top of MbedTLS X509
library.
Introduce _LEGACY and _MBEDTLS kconfigs for X509 cert parser legacy
and MbedTLS implementations respectively.
Signed-off-by: Raymond Mao <raymond.mao@linaro.org>
Raymond Mao [Thu, 3 Oct 2024 21:50:28 +0000 (14:50 -0700)]
mbedtls: add public key porting layer
Add porting layer for public key on top of MbedTLS X509 library.
Introduce _LEGACY and _MBEDTLS kconfigs for public key legacy and
MbedTLS implementations respectively.
Signed-off-by: Raymond Mao <raymond.mao@linaro.org> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Raymond Mao [Thu, 3 Oct 2024 21:50:24 +0000 (14:50 -0700)]
mbedtls/external: update MbedTLS PKCS7 test suites
Update the PKCS7 test suites for multiple certs.
The PR for this patch is at:
https://github.com/Mbed-TLS/mbedtls/pull/9001
For enabling EFI loader PKCS7 features with MbedTLS build,
we need this patch on top of MbedTLS v3.6.0 before it is merged into
the next MbedTLS LTS release.
Signed-off-by: Raymond Mao <raymond.mao@linaro.org> Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Raymond Mao [Thu, 3 Oct 2024 21:50:23 +0000 (14:50 -0700)]
mbedtls/external: support decoding multiple signer's cert
Support decoding multiple signer's cert in the signed data within
a PKCS7 message.
The PR for this patch is at:
https://github.com/Mbed-TLS/mbedtls/pull/9001
For enabling EFI loader PKCS7 features with MbedTLS build,
we need this patch on top of MbedTLS v3.6.0 before it is merged into
the next MbedTLS LTS release.
Signed-off-by: Raymond Mao <raymond.mao@linaro.org>
Raymond Mao [Thu, 3 Oct 2024 21:50:22 +0000 (14:50 -0700)]
mbedtls/external: support PKCS9 Authenticate Attributes
Populate PKCS9 Authenticate Attributes from signer info if it exists
in a PKCS7 message.
Add OIDs for describing objects using for Authenticate Attributes.
The PR for this patch is at:
https://github.com/Mbed-TLS/mbedtls/pull/9001
For enabling EFI loader PKCS7 features with MbedTLS build,
we need this patch on top of MbedTLS v3.6.0 before it is merged into
the next MbedTLS LTS release.
Signed-off-by: Raymond Mao <raymond.mao@linaro.org> Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Raymond Mao [Thu, 3 Oct 2024 21:50:21 +0000 (14:50 -0700)]
mbedtls/external: support Microsoft Authentication Code
Populate Microsoft Authentication Code from the content data
into PKCS7 decoding context if it exists in a PKCS7 message.
Add OIDs for describing objects using for Microsoft Authentication
Code.
The PR for this patch is at:
https://github.com/Mbed-TLS/mbedtls/pull/9001
For enabling EFI loader PKCS7 features with MbedTLS build,
we need this patch on top of MbedTLS v3.6.0 before it is merged into
the next MbedTLS LTS release.
Signed-off-by: Raymond Mao <raymond.mao@linaro.org> Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Raymond Mao [Thu, 3 Oct 2024 21:50:20 +0000 (14:50 -0700)]
mbedtls: Enable smaller implementation for SHA256/512
Smaller implementation for SHA256 and SHA512 helps to reduce the
ROM footprint though it has a certain impact on performance.
As a trade-off, enable it as a default config when MbedTLS is
enabled can reduce the target size significantly with acceptable
performance loss.
Signed-off-by: Raymond Mao <raymond.mao@linaro.org> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
projects / u-boot.git / log