| Age | Commit message (Collapse) | Author |
|
Prepare v2025.10-rc4
|
|
int is not sufficient to hold and test the return from an EFI function
call. Use efi_status_t instead so that the test can work as expected.
This issue was found by Smatch.
Fixes: 275854baeeec ("efi: Add a serial driver")
Signed-off-by: Andrew Goodbody <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
https://source.denx.de/u-boot/custodians/u-boot-microblaze into next
AMD/Xilinx/FPGA changes for v2026.01-rc1
mbv:
- Add it to CI loop
versal2:
- Wire UFS driver
serial:
- Add support for OF_PLATDATA in uartlite
misc:
- Mark some structures as const
|
|
In get_lpuart_clk_rate if the call to clk_get_rate returns an error then
the call to return should pass the value of the error which is in rate
rather than ret which will be 0 as its value is not affected by this
error.
This issue was found by Smatch.
Signed-off-by: Andrew Goodbody <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
The first change is to list DM_DRIVER_ALIAS for compatible string to be
able to match the driver. Only xps one is listed because opb one is likely
unused for quite a long time.
The second change is to add dtplat structure to plat data and fill register
base in probe.
Signed-off-by: Michal Simek <[email protected]>
Link: https://lore.kernel.org/r/b494dbad529e919d33977b8ea6e6dbcd14e78907.1753261604.git.michal.simek@amd.com
|
|
plat data should be used only in probe or of_to_plat to fill it information
from DT. Then in probe platform data should be stored in private structure
which should be used by the other driver functions.
Signed-off-by: Michal Simek <[email protected]>
Link: https://lore.kernel.org/r/8d32af596f80a2220d9f5d7fb98476e6d2b5f303.1753261604.git.michal.simek@amd.com
|
|
Prepare v2025.10-rc3
|
|
serial_find_console_or_panic() may left cur_serial_dev unassigned if
REQUIRE_SERIAL_CONSOLE is not set. Setting GD_FLG_SERIAL_READY in
this situation confuses serial console code. It tries to use
unassigned driver instead of debug port and stops printing.
So check cur_serial_dev before setting GD_FLG_SERIAL_READY to allow
console to keep printing via debug port.
Signed-off-by: Maxim Kochetkov <[email protected]>
|
|
This driver is unused. Remove it.
Signed-off-by: Tom Rini <[email protected]>
|
|
A few serial drivers cannot build without access to some platform
specific header files. Express those requirements in Kconfig as well.
Signed-off-by: Tom Rini <[email protected]>
|
|
The NULL check for priv in qcom_geni_serial_poll_bit serves no useful
prupose as too much other code surrounding it relies on priv being
valid. Remove the NULL check for priv and other related code.
This issue was found by Smatch.
Signed-off-by: Andrew Goodbody <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Casey Connolly <[email protected]>
|
|
In msm_serial_setbrg if the call to get_clk_div_rate fails then there
will not have been an assignment to clk_div which will lead to the call
to geni_serial_baud using an uninitialised value.
Check for an error from get_clk_div_rate and return an error code if so.
This issue was found by Smatch.
Signed-off-by: Andrew Goodbody <[email protected]>
Reviewed-by: Casey Connolly <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Casey Connolly <[email protected]>
|
|
With the removal of the last i.MX31 platform we can remove the rest of
the underlying architecture code as well.
Fixes: f247354708ec ("arm: Remove mx31pdk board")
Signed-off-by: Tom Rini <[email protected]>
Acked-by: Peng Fan <[email protected]>
|
|
The high-speed UART from MediaTek supports baudrate accuracy
compensation when using high-speed mode 3.
This is done by calculating the first digit of the fraction part of
sample count value. The fraction value will be then used as the
reference to insert 0 to 10 sample cycle(s) to one frame (assume
that frame format is 8n1, i.e. 10 bits per frame).
The fracdiv_[l/m] registers are used to determine whether a bit in one frame
should be inserted with one sample cycle.
With typical 40MHz source clock, the actual baudrates with/without
accuracy compensation are:
Ideal w/o compensation w/ compensation
======== ================ ===============
9600 9603 9600
115200 114942 115207
921600 930232 921659
3000000 3076923 3007519
Signed-off-by: Weijie Gao <[email protected]>
|
|
Fix UART register names and offsets according to the programming
guide to allow implementing some enhanced features.
Signed-off-by: Weijie Gao <[email protected]>
|
|
Add useful default debug uart values for all Versal platforms to simplify
and speed up debug uart enabling.
The similar change has been done for Zynq/ZynqMP by commit ad55d99e3cc3
("serial: Setup serial base and freq for zynq/zynqmp").
Signed-off-by: Michal Simek <[email protected]>
Link: https://lore.kernel.org/r/86edf3dbb6de16337aac36f5121f306f83149fc0.1741868624.git.michal.simek@amd.com
|
|
Tom Rini <[email protected]> says:
This series switches to always using $(PHASE_) in Makefiles when
building rather than $(PHASE_) or $(XPL_). It also starts on documenting
this part of the build, but as a follow-up we need to rename
doc/develop/spl.rst and expand on explaining things a bit.
Link: https://lore.kernel.org/r/[email protected]
|
|
It is confusing to have both "$(PHASE_)" and "$(XPL_)" be used in our
Makefiles as part of the macros to determine when to do something in our
Makefiles based on what phase of the build we are in. For consistency,
bring this down to a single macro and use "$(PHASE_)" only.
Signed-off-by: Tom Rini <[email protected]>
|
|
empty/full"
Simon Glass <[email protected]> says:
The membuff implementation curently has no tests. It also assumes that
head and tail can never correspond unless the buffer is empty.
This series provides a compile-time flag to support a 'full' flag. It
also adds some tests of the main routines.
The data structure is also renamed to membuf which fits better with
U-Boot.
There may be some cases in the code which could be optimised a little,
but the implementation is functional.
Link: https://lore.kernel.org/r/[email protected]
|
|
The double 'f' is not necessary and is a bit annoying as elsewhere in
U-Boot we use 'buf'. Rename all the functions before it is used more
widely.
Signed-off-by: Simon Glass <[email protected]>
|
|
Depending on the platform, there may be multiple clock sources
required to enable a UART. Use the bulk functions to get and
enable the clocks when the UART probes. This can facilitate
the removal of functions to manually enable the clock.
This is made dependent on CLK_CCF which is used on imx6q,
imx8m[mnqp], several imxrt, imx9. If/when the UART clock
registration is done for older boards, this limitation
could be updated.
Signed-off-by: Adam Ford <[email protected]>
Reviewed-by: Peng Fan <[email protected]>
|
|
On PowerPC platforms with TPL enabled and SPL_SYS_NS16550_SERIAL
enabled, today this builds under TPL as well due to how $(XPL_) is
defined. Add the TPL_SYS_NS16550_SERIAL itself for consistency and
clarity.
Signed-off-by: Tom Rini <[email protected]>
|
|
https://source.denx.de/u-boot/custodians/u-boot-stm into next
CI: https://source.denx.de/u-boot/custodians/u-boot-stm/-/pipelines/25112
- Add drivers for MFD STM32 TIMERS and STM32 PWM and enable them on stm32mp135f-dk
- Restrict _debug_uart_init() usage in STM32 serial driver
- Add support for environment in eMMC on STM32MP13xx DHCOR SoM
- Introduce DH STM32MP15xx DHSOM board specific defconfigs
- Fix CONFIG_BOOTCOUNT_ALTBOOTCMD update on DH STM32MP1 DHSOM
- Update maintainer for board stm32f746-disco
- Fix Linux cmdline for stm32f769-disco
- Cleanup in stm32f***-u-boot.dtsi and in board_late_init() by removing
legacy led and button management.
|
|
Since commit 948da7773e34 ("arm: Add new config option ARCH_VERY_EARLY_INIT")
debug_uart_init() is called respectively in crt0.S and crt0_64.S.
That means that _debug_uart_init() is called for all STM32MP platforms
even for those which doesn't support SPL_BUILD.
So restrict _debug_uart_init() execution for platforms which can have
SPL_BUILD enabled (STM32MP1 platform only).
It's more needed to call debug_uart_init() in stm32mp1/cpu.c.
Signed-off-by: Patrice Chotard <[email protected]>
Reviewed-by: Patrick Delaunay <[email protected]>
|
|
The lone user of this driver has been removed for some time. Remove this
driver as well.
Signed-off-by: Tom Rini <[email protected]>
Reviewed-by: Mattijs Korpershoek <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mattijs Korpershoek <[email protected]>
|
|
serial_out_dynamic() takes a u8* addr and uses it for 8-bit or 32-bit
accesses, depending on the value of plat->reg_width. This results in a
pointer type mismatch that the compiler may even turn into an error:
drivers/serial/ns16550.c: In function ‘serial_out_dynamic’:
drivers/serial/ns16550.c:115:42: error: passing argument 1 of ‘out_be32’ from incompatible pointer type [-Wincompatible-pointer-types]
115 | out_be32(addr, value);
| ^~~~
| |
| u8 * {aka unsigned char *}
This error was observed on PowerPC.
Signed-off-by: J. Neuschäfer <[email protected]>
|
|
Add compatible string for the Intel XScale variant of the 16550. Needed
to match upstream.
Signed-off-by: Duje Mihanović <[email protected]>
Reviewed-by: Stefan Roese <[email protected]>
|
|
Simon Glass <[email protected]> says:
The current UPL spec[1] has been tidied up and improved over the last
year, since U-Boot's original UPL support was written.
This series includes some prerequisite patches needed for the real UPL
patches. It is split from [2]
[1] https://github.com/UniversalPayload/spec/tree/3f1450d
[2] https://patchwork.ozlabs.org/project/uboot/list/?series=438574&state=*
Link: https://lore.kernel.org/r/[email protected]
|
|
UPL needs to pass the serial details onto the next stage, so adjust the
condition to support this.
Signed-off-by: Simon Glass <[email protected]>
|
|
Prepare v2025.01-rc5
|
|
higher baudrates
Move to OMAP specific implementation of certain ops functions as the UART
prints on the serial console fail for baudrates greater than 460800.
The MDR1 register is responsible for determining the speed mode at which
the UART should operate for OMAP specific devices. The baud divisor is used
to set the UART_DLL register which is used for generation of the baud
clock in the baud rate generator. The implementation logic is similar to
how it is implemented in omap_8250_get_divisor function of 8250_omap UART
linux driver.
Signed-off-by: Gokul Praveen <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Increase scope of ops functions and do some clean up for usage in device
-specific UART drivers.
Remove the static functionality of ops functions and migrate certain macros
to header file for usage in device-specific drivers.
Signed-off-by: Gokul Praveen <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
The correct spelling is R-Car, including the dash, update the usage.
Kconfig strings and comment changes only, no functional change.
Signed-off-by: Marek Vasut <[email protected]>
|
|
Patrick Rudolph <[email protected]> says:
Based on the existing work done by Simon Glass this series adds
support for booting aarch64 devices using ACPI only.
As first target QEMU SBSA support is added, which relies on ACPI
only to boot an OS. As secondary target the Raspberry Pi4 was used,
which is broadly available and allows easy testing of the proposed
solution.
The series is split into ACPI cleanups and code movements, adding
Arm specific ACPI tables and finally SoC and mainboard related
changes to boot a Linux on the QEMU SBSA and RPi4. Currently only the
mandatory ACPI tables are supported, allowing to boot into Linux
without errors.
The QEMU SBSA support is feature complete and provides the same
functionality as the EDK2 implementation.
The changes were tested on real hardware as well on QEMU v9.0:
qemu-system-aarch64 -machine sbsa-ref -nographic -cpu cortex-a57 \
-pflash secure-world.rom \
-pflash unsecure-world.rom
qemu-system-aarch64 -machine raspi4b -kernel u-boot.bin -cpu cortex-a72 \
-smp 4 -m 2G -drive file=raspbian.img,format=raw,index=0 \
-dtb bcm2711-rpi-4-b.dtb -nographic
Tested against FWTS V24.03.00.
Known issues:
- The QEMU rpi4 support is currently limited as it doesn't emulate PCI,
USB or ethernet devices!
- The SMP bringup doesn't work on RPi4, but works in QEMU (Possibly
cache related).
- PCI on RPI4 isn't working on real hardware since the pcie_brcmstb
Linux kernel module doesn't support ACPI yet.
Link: https://lore.kernel.org/r/[email protected]
|
|
When ACPI is enabled on arm it will use the getinfo function to fill
the SPCR ACPI table.
Signed-off-by: Maximilian Brune <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Cc: Simon Glass <[email protected]>
Cc: Tom Rini <[email protected]>
Reviewed-by: Moritz Fischer <[email protected]>
|
|
Rasmus Villemoes <[email protected]> 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/[email protected]
|
|
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 <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
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: Rasmus Villemoes <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Simon Glass <[email protected]> says:
When the SPL build-phase was first created it was designed to solve a
particular problem (the need to init SDRAM so that U-Boot proper could
be loaded). It has since expanded to become an important part of U-Boot,
with three phases now present: TPL, VPL and SPL
Due to this history, the term 'SPL' is used to mean both a particular
phase (the one before U-Boot proper) and all the non-proper phases.
This has become confusing.
For a similar reason CONFIG_SPL_BUILD is set to 'y' for all 'SPL'
phases, not just SPL. So code which can only be compiled for actual SPL,
for example, must use something like this:
#if defined(CONFIG_SPL_BUILD) && !defined(CONFIG_TPL_BUILD)
In Makefiles we have similar issues. SPL_ has been used as a variable
which expands to either SPL_ or nothing, to chose between options like
CONFIG_BLK and CONFIG_SPL_BLK. When TPL appeared, a new SPL_TPL variable
was created which expanded to 'SPL_', 'TPL_' or nothing. Later it was
updated to support 'VPL_' as well.
This series starts a change in terminology and usage to resolve the
above issues:
- The word 'xPL' is used instead of 'SPL' to mean a non-proper build
- A new CONFIG_XPL_BUILD define indicates that the current build is an
'xPL' build
- The existing CONFIG_SPL_BUILD is changed to mean SPL; it is not now
defined for TPL and VPL phases
- The existing SPL_ Makefile variable is renamed to SPL_
- The existing SPL_TPL Makefile variable is renamed to PHASE_
It should be noted that xpl_phase() can generally be used instead of
the above CONFIGs without a code-space or run-time penalty.
This series does not attempt to convert all of U-Boot to use this new
terminology but it makes a start. In particular, renaming spl.h and
common/spl seems like a bridge too far at this point.
The series is fully bisectable. It has also been checked to ensure there
are no code-size changes on any commit.
|
|
Use PHASE_ as the symbol to select a particular XPL build. This means
that SPL_TPL_ is no-longer set.
Update the comment in bootstage to refer to this symbol, instead of
SPL_
Signed-off-by: Simon Glass <[email protected]>
|
|
Use XPL_ as the symbol to indicate an SPL build. This means that SPL_ is
no-longer set.
Signed-off-by: Simon Glass <[email protected]>
|
|
Use the new symbol to refer to any 'SPL' build, including TPL and VPL
Signed-off-by: Simon Glass <[email protected]>
|
|
Give this function a slightly easier name.
Signed-off-by: Simon Glass <[email protected]>
|
|
Initializing a clock driver to read a known static clock rate can take
some time at U-Boot proper pre-reloc phase.
Change to first try and read clock rate from DT to speed up boot time,
fall back to getting the clock rate from clock driver.
This help reduce boot time by around:
- ~35ms on a Radxa ROCK Pi 4 (RK3399)
- ~15ms on a Radxa ZERO 3W (RK3566)
Time that is wasted getting a static rate known at compile time.
Signed-off-by: Jonas Karlman <[email protected]>
Reviewed-by: Quentin Schulz <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Some boards want to use the debug UART in TPL so add an option for that.
Signed-off-by: Simon Glass <[email protected]>
|
|
With sandbox, when U-Boot is waiting for input it syncs the video
display, since presumably the user has finished typing.
Now that cyclic is used for video syncing, we can drop this. Cyclic
will automatically call the video_idle() function when idle.
Signed-off-by: Simon Glass <[email protected]>
|
|
There are no longer any OMAP4 platforms in U-Boot, remove the related
functionality.
Signed-off-by: Tom Rini <[email protected]>
|
|
Drop all duplicate newlines. No functional change.
Signed-off-by: Marek Vasut <[email protected]>
|