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>
(cherry picked from commit 50cc0c16b7)
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>
(cherry picked from commit a9c61ac04f)
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 <marek.vasut+renesas@mailbox.org>
(cherry picked from commit b1c2886cf2)
When characters cannot be sent to the serial port, return an error code
so that the uclass can try again.
This fixes a problem with gnome-terminal which seems to get behind and
then drop output when a large amount of output is produced quickly (e.g.
100K in under a second). Since sandbox often writes to the device one
character at a time it does place a substantial load on the other end of
the PTY. Quite possibly it does not empty the pipe quickly enough and so
writing to the PTY fails.
Signed-off-by: Simon Glass <simon.glass@canonical.com>
If something goes wrong when writing to the serial device, take notice
of the error code and try again, if needed.
Signed-off-by: Simon Glass <simon.glass@canonical.com>
Add support for a 'skip-init' property in the device tree that preserves
UART settings from a previous boot phase.
This is useful when the UART is already configured by firmware (e.g.,
EFI firmware on x86 platforms) and changing the settings would disrupt
console output or cause communication issues.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
The serial driver is currently quite slow since it sets an event and
waits for at least 1ms for a keypress, which may never come.
On real hardware, the keyboard does not work correctly wihout waiting
for events. Reduce the time to 10us which should be enough to provide an
opportunity for event processing.
QEMU does not actually have this problem, so detect that and skip the
processing altogether.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Create a new file in lib/efi to handle conversion of keys from EFI
format to characters, so we can use it from multiple places. Update the
serial_efi driver accordingly.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a new -A sandbox command-line option that sets a flag to assume no
terminal is present. This causes serial_query_size() to return -ENOENT
immediately, similar to when CONFIG_SERIAL_TERM_PRESENT is disabled.
This option is useful for testing pager behavior in non-interactive
environments without needing to modify configuration options.
Co-developed-by: Claude <noreply@anthropic.com>
Add serial_priv structure to serial uclass to cache terminal dimensions.
When serial_query_size() successfully queries the terminal, store the
results in the uclass-private data for later retrieval.
This avoids repeated terminal queries and improves performance when
different subsystems need the terminal size.
Series-changes: 3
- Drop unnecessary 'dev' argument
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
The EFI loader has some code to check the size (rows and columns) of an
attached terminal. Move this over to the serial uclass so that it can be
used elsewhere.
Create a new CONFIG_SERIAL_TERM_PRESENT to control whether it should be
used. Enable that for the EFI loader to preserve existing behaviour.
Adjust the implementation so that it returns a useful error code on
failure. Put the ESC and cESC values in the serial.h header.
Series-changes: 3
- Update comment for serial_query_size()
Signed-off-by: Simon Glass <sjg@chromium.org>
The EFI serial driver checks for keypresses but does not allow other
events to be processed. For devices which have a USB keyboard, the USB
message must be processed before any keys can emerge for the serial
driver to pick up.
Add a periodic timer to the list of events. This allows the keyboard to
work on Qualcomm laptops, for example.
Series-changes: 2
- Add a comment to serial_efi_get_key() about the 1ms delay
Signed-off-by: Simon Glass <sjg@chromium.org>
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>
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>
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>
Patrick Rudolph <patrick.rudolph@9elements.com> 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/20241023132116.970117-1-patrick.rudolph@9elements.com
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>
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>
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
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 <ravi@prevas.dk>
Reviewed-by: Simon Glass <sjg@chromium.org>
Simon Glass <sjg@chromium.org> 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 <sjg@chromium.org>
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 <jonas@kwiboo.se>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
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 <sjg@chromium.org>
Christian Marangi <ansuelsmth@gmail.com> says:
This is an initial series that have all the initial trivial
fixes required for usage of OF_UPSTREAM for the mediatek SoC
This also contains the pcie-gen3 driver and the required tphy
support driver to make it work.
Subsequent series will follow with conversion of the mtk-clk
to permit usage of OF_UPSTREAM and upstream clk ID.
MT7981, MT7986 and MT7988 migration to upstream clock ID
is complete and working on MT7623.
Series CI tested with PR: https://github.com/u-boot/u-boot/pull/590
Upstream linux serial driver use a different logic to setup serial regs.
They have 2 interval:
- < 115200 we use lowspeed regs and 16 * baud
- >= 115200 we use highspeed
We currently use force_highspeed property to force usage of highspeed
regs even with low baud rate.
Add special handling if the upstream compatible is used where we just
apply the same interval with anything >= 115200 in highspeed simulating
force_highspeed.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Upstream linux also provide the additional optional bus clock.
Add support for it and also enable the baud and bus clock on probe.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Jiaxun Yang <jiaxun.yang@flygoat.com> says:
Hi all,
This series enabled qemu-xtensa board.
For dc232b CPU it needs to be built with toolchain[1].
This is a side product of me investigating architectures
physical address != virtual address in U-Boot. Now we can
get it covered under CI and regular tests.
VirtIO devices are not working as expected, due to U-Boot's
assumption on VA == PA everywhere, I'm going to get this fixed
later.
My Xtensa knowledge is pretty limited, Xtensa people please
feel free to point out if I got anything wrong.
Thanks
[1]: https://github.com/foss-xtensa/toolchain/releases/download/2020.07/x86_64-2020.07-xtensa-dc232b-elf.tar.gz
Add xtensa semihosting driver.
It can't use regular semihosting driver as Xtensa's has it's own
semihosting ABI.
Tested-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
watchdog_reset() is no more. Make the comments match the code and
today's reality.
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Stefan Roese <sr@denx.de>
As part of bringing the master branch back in to next, we need to allow
for all of these changes to exist here.
Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>
When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay
Ethernet"' I failed to notice that b4 noticed it was based on next and
so took that as the base commit and merged that part of next to master.
This reverts commit c8ffd1356d, reversing
changes made to 2ee6f3a5f7.
Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>
Greg Malysa <greg.malysa@timesys.com> says:
This series adds support for the ADI SC5xx machine type and includes two
core drivers that are required for being able to boot any board--a UART
driver, the gptimer driver which is used as a clock reference (CNTVCNT
is not supported on the armv7 sc5xx SoCs) and the clock tree driver. Our
corresponding Linux support relies on u-boot configuring the clocks
correctly before booting, so it is not possible to boot any board
without the CGU/CDU configuration happening here. There are also no
board files, device trees, or defconfigs included here, but some common
definitions that will be used to build board files currently are. The
sc5xx SoCs themselves include many armv7 families (sc57x, sc58x, and
sc594) all using an ARM Cortex-A5, and one armv8 family (sc598) indended
to be a drop-in replacement for the SC594 in terms of peripherals, with
a Cortex-A55 instead.
Some of the configuration code in dmcinit and clkinit is quite scary and
causes a lot of checkpatch violations. It is modified from code
initially provided by ADI, but it has not been fully rewritten. There's
a question of how important it is to clean up this code--it has some
quality violations, but it has been in use (including in production) for
over two years and is known to work for performing the low level SoC
initialization, while a rewrite might introduce timing or sequence bugs
that could take a significant amount of time to detect in the future.
Remove <common.h> from this driver directory and when needed
add missing include files directly.
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
SE HMIBSC board uses UART1 as the main debug console, so add
corresponding clocks and pinmux support. Along with that update
instructions to enable clocks for debug UART support.
Reviewed-by: Caleb Connolly <caleb.connolly@linaro.org>
Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
The driver currently requires the bit clock divider be hardcoded in
devicetree (or use the hardcoded default from apq8016).
The bit clock divider is used to derive the baud rate from the core
clock:
baudrate = clk_rate / csr_div
clk_rate is the actual programmed core clock rate which is returned by
clk_set_rate(), and this UART driver only supports a baudrate of 115200.
We can therefore determine the appropriate value for UARTDM_CSR by
iterating over the possible values and finding the one where the
equation above holds true for a baudrate of 115200.
Implement this logic and drop the non-standard DT bindings for this
driver.
Tested on dragonboard410c.
Tested-by: Robert Marko <robert.marko@sartura.hr>
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
MSM serial in DEBUG UART mode is trying to set .clk_rate, but the
msm_serial_data structure does not have such property at all, so lets
remove it as otherwise it will fail compiling.
Fixes: 90023bdfe9 ("serial: msm: add debug UART")
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
Reviewed-by: Caleb Connolly <caleb.connolly@linaro.org>
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
Currently, DEBUG_UART_MSM depends on ARCH_SNAPDRAGON only, but IPQ40XX
devices also use the same UART HW so they can also use the debug UART.
So, allow selecting DEBUG_UART_MSM when using ARCH_IPQ40XX as well.
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
Reviewed-by: Caleb Connolly <caleb.connolly@linaro.org>
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
