Andy Shevchenko [Sat, 5 Oct 2024 19:11:58 +0000 (22:11 +0300)]
x86: cpu: Mark a few functions static
Some functions are not used anywhere except the same file
where they are defined. Mark them static. This helps avoiding
the compiler warnings:
arch/x86/cpu/cpu.c:343:6: warning: no previous prototype for ‘detect_coreboot_table_at’ [-Wmissing-prototypes]
arch/x86/cpu/mtrr.c:90:6: warning: no previous prototype for ‘mtrr_write_all’ [-Wmissing-prototypes]
arch/x86/cpu/i386/interrupt.c:240:6: warning: no previous prototype for ‘__do_irq’ [-Wmissing-prototypes]
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Andy Shevchenko [Sat, 5 Oct 2024 19:11:57 +0000 (22:11 +0300)]
x86: cpu: Use default print_cpuinfo() for all
Most of the copies of the print_cpuinfo() call the default method.
Remove all of those in order to have only the default one when
no `cpu` command is compiled.
This also helps avoiding compiler warning, e.g.:
arch/x86/cpu/tangier/tangier.c:23:5: warning: no previous prototype for ‘print_cpuinfo’ [-Wmissing-prototypes]
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Simon Glass [Mon, 14 Oct 2024 22:31:58 +0000 (16:31 -0600)]
expo: Allow menu items to have values
At present menu items are stored according to their sequence number in
the menu. In some cases we may want to have holes in that sequence, or
not use a sequence at all.
Add a new 'value' property for menu items. This will be used for
reading and writing, if present. If there is no 'value' property, then
the normal sequence number will be used instead.
Simon Glass [Mon, 14 Oct 2024 22:31:57 +0000 (16:31 -0600)]
expo: Use standard numbering for save and discard
Set aside some expo IDs for 'save' and 'discard' buttons. This avoids
needing to store the IDs for these. Adjust the documentation and expo
tool for the new EXPOID_BASE_ID value.
Ignore these objects when saving and loading the cedit, since they do
not contain real data.
Adjust 'cedit run' to return failure when the user exits the expo
without saving. Update the test for this change as well.
Simon Glass [Mon, 14 Oct 2024 22:31:55 +0000 (16:31 -0600)]
expo: Place menu items to the right of all labels
At present a fixed position is used for menu items, 200 pixels to the
right of the left side of the labels. This means that a menu item with
a very long label may overlap the items.
It seems better to calculate the maximum label width and then place the
items to the right of all of them.
To implement this, add a new struct to containing arrangement
information. Calculate it before doing the actual arrangement. Add a
new style item which sets the amount of space from the right side of
the labels to left side of the items.
Simon Glass [Mon, 14 Oct 2024 22:31:54 +0000 (16:31 -0600)]
video: Avoid starting a new line to close to the bottom
When starting a new text line, an assumption is made that the current
vertical position is a multiple of the character height. When this is
not true, characters can be written after the end of the framebuffer.
This can causes crashes and strange errors from QEMU.
Adjust the scrolling check when processing a newline character, to
avoid any problems.
Add some comments to make things a little clearer.
Simon Glass [Mon, 14 Oct 2024 22:31:53 +0000 (16:31 -0600)]
video: Add a dark-grey console colour
This is useful for highlighting something with a black background, as
is needed with cedit when using a white-on-black console. Add this as
a new colour.
Marek Vasut [Sat, 5 Oct 2024 14:33:37 +0000 (16:33 +0200)]
sandbox: dts: Add missing sandbox, emul phandle to sandbox-pmic
This phandle was missing in the sandbox DT, add it, otherwise sandbox-i2c
driver cannot look up the emulator via i2c_emul_find(). This fixes the
following i2c_emul_find() error:
"
$ ./u-boot -Dc ""
...
i2c_emul_find() No emulators for device 'sandbox_pmic'
sandbox_pmic_write() write error to device: 0000000018c568d0 register: 0x0!
out_set_value() PMIC write failed: -5
i2c_emul_find() No emulators for device 'sandbox_pmic'
sandbox_pmic_write() write error to device: 0000000018c568d0 register: 0x0!
out_set_value() PMIC write failed: -5
...
"
Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Heiko Schocher <hs@denx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
Simon Glass [Mon, 30 Sep 2024 18:51:36 +0000 (12:51 -0600)]
u_boot_pylib: Support running coverage on selected functions
At present run_test_coverage() assumes you want code coverage for the
entire code base. This is the normal situation, but sometimes it is
useful to see the coverage provided by just a single test. Add support
for this.
Simon Glass [Wed, 25 Sep 2024 10:44:53 +0000 (12:44 +0200)]
sandbox_spl: Restrict use of UPL when not enabled
With sandbox_spl we want to use the file-based boot in CI, so that this
flow is tested. The recent UPL change enabled booting via that method,
thus overriding the file-based boot.
Correct this by using UPL only when the --upl flag is given.
Signed-off-by: Simon Glass <sjg@chromium.org> Fixes: 91fde8e1764 ("sandbox: Add an SPL loader for UPL")
binman: implement signing FIT images during image build
The patch implement new property 'fit,sign' that can be declared
at the top-level 'fit' node. If that option is declared, fit tryies
to detect private keys directory among binman include directories.
That directory than passed to mkimage using '-k' flag and that enable
signing of FIT.
Signed-off-by: Alexander Kochetkov <al.kochet@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Renumbered files, moved new tests to end: Signed-off-by: Simon Glass <sjg@chromium.org>
binman: fix passing loadables to mkimage on first run
FIT use mkimage from BuildSectionData() to build FIT entry contents.
BuildSectionData() get called several times during building FIT image.
Currently when fit inserts loadables, it use self._loadables property that
contain loadables computed during previuos BuildSectionData() invocation.
So for the first run it use empty list and pass no loadables to mkimage.
That makes problem for adding signature to FIT image because mkimage
fails to add signature and aborts building FIT if no loadables provided.
The patch fixes described behaviour in a way that BuildSectionData() uses
recently calculated loadables value, not previosly calculated.
Signed-off-by: Alexander Kochetkov <al.kochet@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
When BLK is not enabled but BOOTSTD is, some features of standard boot
become unavailable. Add a check for this in the only site that is
currently apparent.
Simon Glass [Sun, 1 Sep 2024 22:27:27 +0000 (16:27 -0600)]
blk: Make functions available unconditionally
Some boards still don't enable BLK but we want to be able to at least
compile the code which relies on this. For example, bootstd includes
calls to blk_...() functions, albeit with a check for BLK so that the
code is eliminated by the compiler.
Reduce the scope of the BLK #ifdef to help with this.
Simon Glass [Wed, 28 Aug 2024 01:44:26 +0000 (19:44 -0600)]
x86: Avoid timer-clock overflow
When the clock speed is above about 4GHz, e.g. on modern PC hardware,
the timer overflows, resulting in a much lower frequency than expected.
Deal with this by capping the clock speed.
It would be possible to move to a 64-bit value for the clock, but that
is a pain to deal with. A better approach might be to express the clock
in MHz but that is left for later consideration.
Tom Rini [Mon, 22 Jan 2024 14:35:12 +0000 (09:35 -0500)]
x86: Make default_print_cpuinfo be a weak alias for print_cpuinfo
While a few SoCs have a unique print_cpuinfo function, a number of them
just use default_print_cpuinfo. Make default_print_cpuinfo have a weak
alias to provie print_cpuinfo.
Simon Glass [Mon, 8 Jan 2024 00:14:55 +0000 (17:14 -0700)]
coreboot: Switch to a monospaced font
The default font is proportional, with different character widths.
Select a monospace font for coreboot so that the 'dm tree' output lines
up correctly.
- Switch to using upstream DT on DH i.MX8MP DHCOM PDK2/PDK3.
- Add ability to build fallback DTBOs from arch/$(ARCH)/dts.
- Remove fdt_high and initrd_high env variables from imx6-dhcom.
- Add dummy clk for imx8.
- Fix DT corruption in imx8_cpu.
- Improve DDR stability on pico-imx7d.
Tom Rini [Tue, 15 Oct 2024 01:33:10 +0000 (19:33 -0600)]
Azure: Update to latest containers
Soon Azure will be removing the macOS-12 container in following their
normal support schedule. Move us to macOS-14 so we won't have problems
there for a while. At the same time, our Windows container is the oldest
supported, so move to the newer option. Finally, Ubuntu 22.04 is the
middle option currently, but 24.04 should be fine.
Peng Fan [Fri, 18 Oct 2024 07:34:32 +0000 (15:34 +0800)]
cpu: imx8_cpu: Avoid revision to corrupt device tree
U-Boot device tree is padded just after U-Boot proper.
After the whole stuff loaded to DRAM space, the device tree
area is conflict with BSS region before U-Boot relocation.
So any write to BSS area before reloc_fdt will corrupt the
device tree. Without the fix, there is issue that “binman_init
failed:-2” on i.MX8MP-EVK board.
Drop 'revision' and use malloc area in cpu_imx_plat->rev.
Marek Vasut [Tue, 15 Oct 2024 23:44:32 +0000 (01:44 +0200)]
ARM: dts: imx6-dhcom: Remove fdt_high and initrd_high env variables
Remove both "fdt_high" and "initrd_high" environment variables
in favor of "bootm_size" to safely contain a kernel, device tree
and initrd for relocation inside of 256 MiB region of DRAM.
Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Fabio Estevam <festevam@gmail.com>
Marek Vasut [Thu, 17 Oct 2024 01:19:17 +0000 (22:19 -0300)]
arm64: dts: imx: Switch to using upstream DT on DH i.MX8MP DHCOM PDK2/PDK3
Enable OF_UPSTREAM to use upstream DT and add freescale/ prefix to the
DEFAULT_DEVICE_TREE. And thereby directly build DTB from dts/upstream/src/
including *-u-boot.dtsi and DTBOs from arch/$(ARCH)/dts/ directory.
Reviewed-by: Sumit Garg <sumit.garg@linaro.org> Signed-off-by: Marek Vasut <marex@denx.de>
Marek Vasut [Thu, 17 Oct 2024 01:08:40 +0000 (03:08 +0200)]
dts: Add ability to build fallback DTBOs from arch/$(ARCH)/dts
Currently the enablement of OF_UPSTREAM results on the build system
searching for DTs only in dts/upstream/ . There are platforms which
use U-Boot specific DTBOs applied on top of U-Boot control DT during
SPL stage, and source DTs for these are located in arch/$(ARCH)/dtb.
Add dedicated 'dtbos' target which builds only .dtbos and not .dtbs and
in case CONFIG_OF_UPSTREAM_INCLUDE_LOCAL_FALLBACK_DTBOS is enabled, build
this target for arch/$(ARCH)/dtb to generate local U-Boot specific DTBOs.
Adjust top level Makefile so binman would search for .dtb and .dtbo in
both OF_UPSTREAM specific paths and arch/$(ARCH)/dtb for the .dtbo case
in case CONFIG_OF_UPSTREAM_INCLUDE_LOCAL_FALLBACK_DTBOS is enabled.
Reviewed-by: Sumit Garg <sumit.garg@linaro.org> Signed-off-by: Marek Vasut <marex@denx.de>
Alexander Dahl [Tue, 1 Oct 2024 12:07:33 +0000 (14:07 +0200)]
ARM: at91: clock: Add missing include of asm/io.h
In one inline function in this header `readl()` is used, but the
declaration was not found, so buildman gave this warning:
w+include/asm/arch/clk.h: In function 'get_h32mxdiv':
w+include/asm/arch/clk.h:65:16: warning: implicit declaration of function 'readl' [-Wimplicit-function-declaration]
Tom Rini [Thu, 17 Oct 2024 21:13:27 +0000 (15:13 -0600)]
Merge patch series "Cleanup dma device in spl and move dma channel[0]"
Prasanth Babu Mantena <p-mantena@ti.com> says:
The channel allocation and deallocation for dma copy was happening on every
dma transfer. This is a overhead for transactions like NAND, which does
page reads recursively for complete data.
So, moving the dma allocation to probe and implement corresponding
remove function and cleanup dma device while exiting from spl.
Enable SPL_DM_DEVICE_REMOVE, for device removal capability in SPL.
dma: ti: k3-udma: Move DMA channel[0] allocation to probe and add udma_remove()
Currently, the allocation of DMA channel[0] for memcpy is happening
in udma_transfer() for every transfer, which leads to a huge overhead
for each transfer, especially in case of nand page reads. So, move this
allocation to udma_probe(), as a result, the allocation is done once
during probe.
Introduce udma_remove() for the cleanup of allocated channel during
probe.
Signed-off-by: Santhosh Kumar K <s-k6@ti.com> Signed-off-by: Prasanth Babu Mantena <p-mantena@ti.com>
dma: ti: k3-udma: Move udma_probe() below all APIs
The udma_probe() function was placed above many important APIs
related to bcdma, pktdma, which restricts these APIs to be accessed
during probe. So, move udma_probe() below all of them.
Signed-off-by: Santhosh Kumar K <s-k6@ti.com> Signed-off-by: Prasanth Babu Mantena <p-mantena@ti.com>
While exiting from spl, remove any dma device active through
spl_board_prepare_for_boot(). This is required for cleaning up
any dma channels being used in spl and avoid issues with overlapping
channel allocation in the next stage bootloaders.
Andy Shevchenko [Sat, 5 Oct 2024 19:14:29 +0000 (22:14 +0300)]
cmd: irq: Move do_irqinfo() prototype to a header file
Move do_irqinfo() prototype to a header file, otherwise compiler is not
happy:
arch/x86/lib/interrupts.c:130:5: warning: no previous prototype for ‘do_irqinfo’ [-Wmissing-prototypes]
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Simon Glass <sjg@chromium.org>
[trini: Add 'struct cmd_tbl;' to irq_func.h] Signed-off-by: Tom Rini <trini@konsulko.com>
AM62x devices now support CPU throttling based on thermal alerts
with a Linux commit 10e7bfd8114c ("arm64: dts: ti: k3-am62: Enable
CPU freq throttling on thermal alert"). However, this functionality
does not work correctly across all variants of the AM62x SoCs
which have different numbers of Cortex-A CPU cores: AM62x1 (1 core),
AM62x2 (2 cores), and AM62x4 (4 cores). On single-core and dual-core
AM62x devices, the following error is observed in the Linux kernel:
OF: /thermal-zones/main0-thermal/cooling-maps/map0: could not find
phandle 94
OF: /thermal-zones/main1-thermal/cooling-maps/map0: could not find
phandle 94
This commit adds a fixup to dynamically adjust the cooling-device
nodes in the thermal zones based on the actual number of CPU cores
available. This resolves the issue of CPU throttling not working
correctly on single-core and dual-core AM62x devices, while
maintaining the functionality for AM62x quad-core devices.
A similar approach is implemented for example on i.MX8MM SoC.
Lad Prabhakar [Tue, 1 Oct 2024 09:56:47 +0000 (10:56 +0100)]
lib: fdtdec: Parse the gzip/lzo headers only when dependencies have met
It might happen that CONFIG_GZIP and CONFIG_LZO are enabled but we might
have CONFIG_MULTI_DTB_FIT_LZO enabled in this case in the code path of
uncompress_blob() we parse the gzip headers first which results in
`Error: Bad gzipped data` being printed. To avoid this parse the gzip/lzo
headers only when dependencies have met.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Tom Rini <trini@konsulko.com>
Jan Kiszka [Mon, 30 Sep 2024 10:20:36 +0000 (12:20 +0200)]
Extend usage for OF_OVERLAY_LIST beyond SPL
Allow to use OF_OVERLAY_LIST also for the case that the overlays just
need be built, e.g. when they will be picked up by binman as artifacts
of the final U-Boot image. The IOT2050 boards have such a need when
switching to OF_UPSTREAM.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Reviewed-by: Sumit Garg <sumit.garg@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org>
- 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
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>
serial: embed the rx buffer in struct serial_dev_priv
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: Simon Glass <sjg@chromium.org>
serial: add build-time sanity check of CONFIG_SERIAL_RX_BUFFER_SIZE
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: Rasmus Villemoes <ravi@prevas.dk> Reviewed-by: Simon Glass <sjg@chromium.org>
serial: do not overwrite not-consumed characters in rx buffer
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: Rasmus Villemoes <ravi@prevas.dk> Reviewed-by: Simon Glass <sjg@chromium.org>
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
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: Rasmus Villemoes <ravi@prevas.dk> Reviewed-by: Simon Glass <sjg@chromium.org>
Marek Vasut [Sat, 12 Oct 2024 02:54:17 +0000 (04:54 +0200)]
ARM: stm32: Add script to install U-Boot from SD/eMMC to SPI NOR on DH STM32MP15xx DHSOM
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: Marek Vasut <marex@denx.de> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Patrick Delaunay [Fri, 11 Oct 2024 15:31:51 +0000 (17:31 +0200)]
stm32mp: fix name of optee reserved memory node
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: 5fe9e0deabb1 ("stm32mp: allow calling optee_get_reserved_memory()
from U-Boot") Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Patrick Delaunay [Fri, 11 Oct 2024 15:31:49 +0000 (17:31 +0200)]
ARM: stm32mp: enable data cache after LMB configuration for STM32MP1
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: ed17a33fed29 ("lmb: make LMB memory map persistent and global") Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Patrick Delaunay [Fri, 11 Oct 2024 15:31:48 +0000 (17:31 +0200)]
stm32mp: compute ram_top based on the optee base address only for STM32MP1
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: 8242f14a3e6f ("stm32mp: compute ram_top based on the optee base address") Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Marek Vasut [Sat, 5 Oct 2024 01:15:50 +0000 (03:15 +0200)]
ARM: dts: stm32: Generate u-boot.itb using binman on DH STM32 DHSOM
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: Marek Vasut <marex@denx.de> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Marek Vasut [Sat, 5 Oct 2024 01:15:49 +0000 (03:15 +0200)]
ARM: dts: stm32: Switch to using upstream DT on DH STM32 DHSOM
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: Marek Vasut <marex@denx.de> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Marek Vasut [Sat, 5 Oct 2024 01:15:48 +0000 (03:15 +0200)]
ARM: dts: stm32: Duplicate cpu0-opp-table node into stm32mp15-u-boot.dtsi
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: Marek Vasut <marex@denx.de> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.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.
projects / u-boot.git / log