| Age | Commit message (Collapse) | Author |
|---|
|
After years of developing the ADI ADSP platform, Timesys was purchased
by another company and is no longer contracted to maintain the platform.
Signed-off-by: Philip Molloy <philip.molloy@analog.com>
Reviewed-by: Greg Malysa <malysagreg@gmail.com>
|
|
Currently, atmel-usart does not respect CONFIG_DEBUG_UART_SKIP_INIT so
it will always configure the debug UART.
However, this is unwanted on platforms on which TF-A or some other firmware
has already configured the debug UART.
This will be used for Microchip LAN969x support, so simply return early if
CONFIG_DEBUG_UART_SKIP_INIT is set.
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
|
|
Microchip LAN969x will not include any arch specific clk.h nor hardware.h,
so in order to support it only include <asm/arch/clk.h> and
<asm/arch/hardware.h> when AT91 is selected.
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
|
|
Move the arch specific atmel_serial.h header from AT91 to the generic
include/dm/platform_data.
This will be used for support on Microchip LAN969x.
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
|
|
Add support for the Google Goldfish TTY serial device. This virtual
device is commonly used in QEMU virtual machines (such as the m68k
virt machine) and Android emulators.
The driver implements basic console output and input polling using the
Goldfish MMIO interface.
Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com>
Reviewed-by: Yao Zi <me@ziyao.cc>
Tested-by: Daniel Palmer <daniel@0x0f.com>
Acked-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <simon.glass@canonical.com>
Acked-by: Angelo Dureghello <angelo@kernel-space.org>
|
|
It is very limited and minimal, only implements putc/puts.
This minimal driver is intended to be used in SPL, and other
size-constrained situations.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Ferass El Hafidi <funderscore@postmarketos.org>
Link: https://patch.msgid.link/20251126-spl-gx-v5-3-6cbffb2451ca@postmarketos.org
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
|
|
Add the compatible for Exynos8895 UART as described in upstream
devicetree bindings. This enables support for Exynos8895 and other
similar UART devices, such as Exynos7870. Other than that, the driver
works as-is.
Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
Reviewed-by: Henrik Grimler <henrik@grimler.se>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
|
|
I have a hunch VPL_DM_SERIAL should not be selectable if VPL isn't set
as implied by the prefix. Additionally, still based on the prefix, I'm
assuming VPL_DM should be a dependency. Since VPL_DM can only be
selectable when VPL is enabled, only depend on VPL_DM.
This mirrors SPL_DM_SERIAL and TPL_DM_SERIAL so seems right to me.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
Teach the GENI UART driver to load firmware, similar to i2c.
This is primarily intended for non-debug UARTs, but since we don't
support using these as the console we abort probe for now.
Remove duplicated register macros that are in the common geni-se header.
Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
Link: https://patch.msgid.link/20250714-geni-load-fw-v5-7-5abbc0d29838@linaro.org
Signed-off-by: Casey Connolly <kcxt@postmarketos.org>
|
|
Enable the serial engine clk in probe so that this driver can work on
platforms that don't already initialize the clk for this device before
this driver runs. This fixes a problem I see on Coreboot platforms like
Trogdor where the UART hardware isn't enabled by coreboot unless the
serial console build is used.
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Link: https://patch.msgid.link/20250714-geni-load-fw-v5-6-5abbc0d29838@linaro.org
Signed-off-by: Casey Connolly <kcxt@postmarketos.org>
|
|
Qualcomm peripherals like UART, SPI, I2C, etc are all exposed under a
common GENI Serial Engine wrapper device. Replace the stub driver we use
for this currently with a full-on misc device and implement support for
loading peripheral firmware.
Each of the peripherals has it's own protocol-specific firmware, this is
stored on the internal storage of the device with a well-known partition
type GUID.
To support this, GENI will bind peripherals in two stages. First the
ones that already have firmware loaded (such as the serial port) are
bound in the typical way. But devices that require firmware loading are
deferred until EVT_LAST_STAGE_INIT. At this point we can be sure that
the storage device is available, so we load the firmware and then bind
and probe the remaining children.
Child devices are expected to determine if firmware loading is necessary
and call qcom_geni_load_firmware().
Since Linux currently doesn't support loading firmware (and firmware may
not be available), we probe all GENI peripherals to ensure that they
always load firmware if necessary.
Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
Link: https://patch.msgid.link/20250714-geni-load-fw-v5-3-5abbc0d29838@linaro.org
Signed-off-by: Casey Connolly <kcxt@postmarketos.org>
|
|
The UART DM controller supports different channel data packing modes,
either the 4-character packing mode (where 32-bit are read/written at once)
or the single-character mode (where only a single character is read/written
at a time). The 4-character mode can be more efficient, but the
single-character mode is much easier to implement.
At the moment, serial_msm uses the 4-character mode. Since the
dm_serial_ops operate on one character at the time, the code goes through
quite some hoops in order to break this down to single characters. This
code is prone to race conditions (e.g. priv->chars_cnt is read from the
registers, then a command is issued, what if another char came in
inbetween?). It also seems to cause another subtle issue with autoboot:
Unlike the previous autoboot failures that happened when UART was
disconnected, this problem occurs when UART is connected and open in a
terminal: For EFI boot, the console size is queried in efi_console.c
query_console_serial() by sending an ANSI escape code via UART. For some
reason, with the current driver we get yet another 0x00 byte (UART break
event?) when reading the reply from serial input. Because of that, reading
the console size fails in efi_console.c, the actual reply remains in the
UART buffer, and later the boot flow aborts because it detects input after
printing a prompt.
Rather than trying to fix the issue in the current complicated approach,
switch the driver to use the single-character mode. This is simple and
straightforward to implement without race conditions:
- We write one character at a time to UARTDM_TF, as long as the TX FIFO
has space available (TX_READY). To flush the console before starting
Linux, we wait for TX_EMPTY.
- We read one character at a time from UARTDM_RF and strip off the
additional error information (assuming there is something in the
RX FIFO, as indicated by RX_READY).
In this mode, querying the serial console size works and autoboot is no
longer interrupted. The overall code is also much shorter.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
Tested-by: Alexey Minnekhanov <alexeymin@minlexx.ru>
Acked-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250908-db410c-autoboot-fixes-v2-6-316ed98e0143@linaro.org
Signed-off-by: Casey Connolly <kcxt@postmarketos.org>
|
|
The documentation for the UART controller in the APQ8016E specifies that
both RESET and ENABLE commands must be issued to set up the receiver and
transmitter, but at the moment we only issue RESET. This doesn't seem to
cause issues in practice (looks like the reset already re-enables the
receiver/transmitter), but let's add the two writes to RX_ENABLE/TX_ENABLE
to better match the recommendations in the documentation.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
Tested-by: Alexey Minnekhanov <alexeymin@minlexx.ru>
Acked-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250908-db410c-autoboot-fixes-v2-5-316ed98e0143@linaro.org
Signed-off-by: Casey Connolly <kcxt@postmarketos.org>
|
|
According to the documentation of the UART controller in the APQ8016E TRM,
clearing bits inside UARTDM_DMEN requires resetting the transmitter and/or
receiver. We do reset inside uart_dm_init(), but before writing to
UARTDM_DMEN. This doesn't seem to cause problems in practice, but let's
move the reset to the end of uart_dm_init() to better match the
recommendations in the documentation.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
Tested-by: Alexey Minnekhanov <alexeymin@minlexx.ru>
Acked-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250908-db410c-autoboot-fixes-v2-4-316ed98e0143@linaro.org
Signed-off-by: Casey Connolly <kcxt@postmarketos.org>
|
|
Some of the register definitions are inconsistently named (likely copied
as-is from Qualcomm's Little Kernel/LK bootloader, which uses the
MSM_BOOT_UART naming scheme). Rename them to be in line with the other
register definitions and move them up to be next to the related register.
No functional change.
Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
Tested-by: Alexey Minnekhanov <alexeymin@minlexx.ru>
Acked-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250908-db410c-autoboot-fixes-v2-3-316ed98e0143@linaro.org
Signed-off-by: Casey Connolly <kcxt@postmarketos.org>
|
|
There have been issues with autoboot on DB410c for years, where autoboot
gets interrupted by spurious input on the UART console. Back in 2021, I've
tried to fix this by inserting a delay before UART initialization, but it
has turned out this is not working reliably either.
It looks like the root cause has always been the lack of bias-pull-up,
which was causing the RX line to be floating when UART is disconnected.
The delay does not seem to be needed anymore when applying bias-pull-up,
so drop it again in favor of the proper fix.
This reverts commit ad7e967738a9c639e07cf50b83ffccdf9a8537b0.
Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
Tested-by: Alexey Minnekhanov <alexeymin@minlexx.ru>
Acked-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250908-db410c-autoboot-fixes-v2-2-316ed98e0143@linaro.org
Signed-off-by: Casey Connolly <kcxt@postmarketos.org>
|
|
The previous description "Qualcomm snapdragon" barely tells the user
anything, update the name so that it's clear which configs the user can
choose between, namely the older QUP driver, or the newer GENI driver.
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20250924-2025-10-misc-v1-3-7e75842ca714@fairphone.com
Signed-off-by: Casey Connolly <kcxt@postmarketos.org>
|
|
The HSCIF RX FIFO may overflow when data are streaming from remote end
into the HSCIF while U-Boot is still starting up. In that case, HSFSR
bit RDF is set, but HSFDR field R is zero. This confuses .tstc callback
into considering RX FIFO to be empty, which leads to .getc to be never
invoked, even when user attempts to pass more input onto the command
line.
Fix this by considering the RDF flag in serial_rx_fifo_level(), which
is called from .tstc in case of no errors. If RDF flag is set, trigger
the .getc callback and let it clear the RX FIFO.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
|
|
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 <andrew.goodbody@linaro.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
|
|
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 <andrew.goodbody@linaro.org>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
|
|
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 <michal.simek@amd.com>
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 <michal.simek@amd.com>
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 <fido_max@inbox.ru>
|
|
This driver is unused. Remove it.
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
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 <trini@konsulko.com>
|
|
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 <andrew.goodbody@linaro.org>
Link: https://lore.kernel.org/r/20250811-serial_msm_geni-v1-2-4499179491bc@linaro.org
Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
|
|
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 <andrew.goodbody@linaro.org>
Reviewed-by: Casey Connolly <casey.connolly@linaro.org>
Link: https://lore.kernel.org/r/20250811-serial_msm_geni-v1-1-4499179491bc@linaro.org
Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
|
|
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 <trini@konsulko.com>
Acked-by: Peng Fan <peng.fan@nxp.com>
|
|
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 <weijie.gao@mediatek.com>
|
|
Fix UART register names and offsets according to the programming
guide to allow implementing some enhanced features.
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
|
|
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 <michal.simek@amd.com>
Link: https://lore.kernel.org/r/86edf3dbb6de16337aac36f5121f306f83149fc0.1741868624.git.michal.simek@amd.com
|
|
Tom Rini <trini@konsulko.com> 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/20250401225851.1125678-1-trini@konsulko.com
|
|
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 <trini@konsulko.com>
|
|
empty/full"
Simon Glass <sjg@chromium.org> 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/20250318152059.1464369-1-sjg@chromium.org
|
|
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 <sjg@chromium.org>
|
|
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 <aford173@gmail.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
|
|
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 <trini@konsulko.com>
|
|
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 <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
|
|
The lone user of this driver has been removed for some time. Remove this
driver as well.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Link: https://lore.kernel.org/r/20250227205101.4127604-2-trini@konsulko.com
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
|
|
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 <j.ne@posteo.net>
|
|
Add compatible string for the Intel XScale variant of the 16550. Needed
to match upstream.
Signed-off-by: Duje Mihanović <duje.mihanovic@skole.hr>
Reviewed-by: Stefan Roese <sr@denx.de>
|
|
Simon Glass <sjg@chromium.org> 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/20250111000029.245022-1-sjg@chromium.org
|
|
UPL needs to pass the serial details onto the next stage, so adjust the
condition to support this.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
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 <g-praveen@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
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 <g-praveen@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
