The dcache flushing code path was conditional on ARM && !DCACHE config
options. However, dcaches exist on other platforms as well and may need
clearing if their driver requires it.
Simplify the compile logic and always enable the dcache flush logic in
the video core. That way, drivers can always rely on it to call the arch
specific callbacks.
This will increase code size for non-ARM platforms with CONFIG_VIDEO=y
slightly.
Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@csgraf.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Link: https://lore.kernel.org/u-boot/20230821135111.3558478-13-alpernebiyasak@gmail.com/
Added workaround for CONFIG_SYS_CACHELINE_SIZE for ibex-ast2700:
Signed-off-by: Simon Glass <sjg@chromium.org>
CONFIG_VIDEO_COPY implemented a range-based copying mechanism: If we
print a single character, it will always copy the full range of bytes
from the top left corner of the character to the lower right onto the
uncached frame buffer. This includes pretty much the full line contents
of the printed character.
Since we now have proper damage tracking, let's make use of that to reduce
the amount of data we need to copy. With this patch applied, we will only
copy the tiny rectangle surrounding characters when we print them,
speeding up the video console.
After this, changes to the main frame buffer are not immediately copied
to the copy frame buffer, but postponed until the next video device
sync. So issue an explicit sync before inspecting the copy frame buffer
contents for the video tests.
Signed-off-by: Alexander Graf <agraf@csgraf.de>
[Alper: Rebase for fontdata->height/w, fill_part(), fix memmove(dev),
drop from defconfig, use damage.xstart/yend, use IS_ENABLED(),
call video_sync() before copy_fb check, update video_copy test]
Co-developed-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Link: https://lore.kernel.org/u-boot/20230821135111.3558478-12-alpernebiyasak@gmail.com/
We are going to introduce image damage tracking to fasten up screen
refresh on large displays. This patch adds damage tracking for up to
one rectangle of the screen which is typically enough to hold blt or
text print updates. Callers into this API and a reduced dcache flush
code path will follow in later patches.
Signed-off-by: Alexander Graf <agraf@csgraf.de>
Reported-by: Da Xue <da@libre.computer>
[Alper: Use xstart/yend, document new fields, return void from
video_damage(), declare priv, drop headers, use IS_ENABLED()]
Co-developed-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Link: https://lore.kernel.org/u-boot/20230821135111.3558478-5-alpernebiyasak@gmail.com/
Reviewed-by: Simon Glass <sjg@chromium.org>
The video tests have a helper function to generate a pseudo-digest of
frame buffer contents, but it only does so for the main one. There is
another check that the copy frame buffer is the same as that. But
neither is enough to test if only the modified regions are copied to the
copy frame buffer, since we will want the two to be different in very
specific ways.
Add a boolean argument to the existing helper function to indicate which
frame buffer we want to inspect, and update the existing callers.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Link: https://lore.kernel.org/u-boot/20230821135111.3558478-3-alpernebiyasak@gmail.com/
While checking frame buffer contents, the video tests also check if the
copy frame buffer contents match the main frame buffer. To test if only
the modified regions are updated after a sync, we will need to create
situations where the two are mismatched. Split this check into another
function that we can skip calling, since we won't want it to error on
those mismatched cases.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Link: https://lore.kernel.org/u-boot/20230821135111.3558478-2-alpernebiyasak@gmail.com/
BOOTSTAGE_RECORD_COUNT=30 is too small to record booting a FIT image
with EFI kernel, initrd, dtb as seen on the StarFive VisionFive 2
board.
Increase the default for BOOTSTAGE_RECORD_COUNT to 50.
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
The EFI sub-system needs the load address and not the entry point
to boot the binary passed from the bootm command. The entry point
is derived from the PE-COFF header of the binary.
Fixes: ecc7fdaa9e ("bootm: Add a bootm command for type IH_OS_EFI")
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
The code-block directive requires addition of the prompt symbol for each
line, using the prompt directive instead allows for auto insertion of
the symbol per line[1].
For the readers, the character added by the prompt directive is
un-selectable i.e the entire line can be more easily selected for copy
pasting etc. Whereas with code-block, the prompt symbol like "$" is also
selectable which is usually not the intent.
This is mostly a QoL addition + making the docs consistent since k3.rst
makes use of prompt directives which these board docs include from.
[1]: https://pypi.org/project/sphinx-prompt/
Signed-off-by: Anshul Dalal <anshuld@ti.com>
Do not try to create an initrd device path nor try to register
an initrd with the EFI_LOAD_FILE2_PROTOCOL if none is provided.
Handle initrd installation in efi_binary_run_dp with
efi_install_initrd, imitating what is done for the fdt.
Fixes: 36835a9105 ("efi_loader: binary_run: register an initrd")
Reported-by: Weizhao Ouyang <o451686892@gmail.com>
Signed-off-by: Adriano Cordova <adriano.cordova@canonical.com>
Tested-by: Weizhao Ouyang <o451686892@gmail.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
It's currently possible to make the bootloader crash on calling
clk_set_rate caused by the loop in clk_clean_rate_cache.
The loop assume that every child of the clock node are also clock
device but this is not always the case. For example it's common for a
clock to bind to a reset device or also expose a syscon if the clock
register map is also used to apply special configuration.
In such case, on accessing a device as a clock, the bootloader crash. To
correctly handle this, check if the child device is actually a clock and
ignore otherwise.
Fixes: 6b7fd3128f ("clk: fix set_rate to clean up cached rates for the hierarchy")
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Michael Trimarchi <michael@amarulasolutions.com>
CONFIG_SYS_NONCACHED_MEMORY is defined as hex, not bool. It should be
replaced with CONFIG_SYS_HAS_NONCACHED_MEMORY when switched from #ifdef to
CONFIG_IS_ENABLED().
Fixes: 6c171f7a18 (common: board: make initcalls static)
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
Tested-by: Marcel Ziswiler <marcel.ziswiler@codethink.co.uk> # rock5b
Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org>
QSPI driver performs chip select operation before every read/write
access. During this operation, driver needs to enable and disable
the QSPI controller. This may cause data loss if there is inadvertent
halting of any ongoing read/write operation. To avoid this scenario,
waiting for the QSPI status to be idle before next read/write
operation is implemented.
Signed-off-by: Naresh Kumar Ravulapalli <nareshkumar.ravulapalli@altera.com>
Reviewed-by: Tien Fong Chee <tien.fong.chee@intel.com>
At the moment a mixture of ifdef(CONFIG_IS_ENABLED) and
CONFIG_IS_ENABLED(SPI_FLASH_BAR) is used in the spi-nor framework.
This leads to misbehaviour in the SPL as there is no Kconfig option
CONFIG_SPL_SPI_FLASH_BAR. This commit standardizes the use of
CONFIG_SPI_FLASH to get SPLs that load U-Boot proper from the
SPI flash to work again.
Fixes: 9bb02f7 (mtd: spi-nor: Fix the spi_nor_read() when config SPI_STACKED_PARALLEL is enabled)
Signed-off-by: Bernhard Messerklinger <bernhard.messerklinger@br-automation.com>
Since the opcode SPINOR_OP_CHIP_ERASE (0xc7) is not supported
for the mt35xu01g/2g flashes, the NO_CHIP_ERASE flag has been added
to enable sector erase functionality instead.
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
This adds the vexpress_fvp and vexpress_fvp_bloblist platforms to the
list of platforms we test via emulator in CI. In order to do this we
need to first have our container runtime have TF-A builds for the
vexpress_fvp platform, both with and without transfer list support as
well as installing "telnet" so that we can access console. In the CI
files we check for the existence of /opt/tf-a/${TEST_PY_BD} and if
found, copy bl1.bin and fip.bin to /tmp and set the variables so that we
can later run FVP to run.
Note that we currently disable the hostfs (semihosting) tests as they
trigger a bug in FVP. This has been reported upstream, and can be
enabled when fixed.
Reviewed-by: Harrison Mutai <harrison.mutai@arm.com>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
The mtd partition offset must be calculated first as it will be
referenced when calculating the mtd partition size.
Change-Id: Iccfd101b0a9597ac240c25670da638a82af28980
Fixes: 1ca97ee903 (mtd: mtdpart: Support MTD_SIZE_REMAINING with unallocated memory area)
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
Reported-by: Francesco Dolcini <francesco@dolcini.it>
getopt_long() expects a NULL-terminated list of structures. The current
list in mkimage does not have a zero-filled structure at the end, which
can cause getopt_long() to walk past the end of the array when passing
an unknown option, causing a segmentation fault.
As a reproducer, the following command causes a segmentation fault
(tested in Debian 12):
mkimage --foobar
Signed-off-by: Carlos López <carlos.lopezr4096@gmail.com>
The LMB memory region attributes flags are used to specify the
behaviour of the memory regions with respect to allocations -- for
e.g. it is allowed to re-allocate a memory region already reserved
with the LMB_NONE flag. The flags use values with different bit
positions through the BIT() macro. Move the LMB_NOMAP value to bit
position 1, and also move the other flags accordingly. Using bit
position 0 for LMB_NOMAP results in the logic in
lmb_print_region_flags() to break, which prints an incorrect value for
the regions with LMB_NOMAP atribute.
Fixes: 3d56c06551 ("lmb: Move enum lmb_flags to a u32")
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
fix the following typos
- from "categorys" to "categories"
- from "indivdually" to "individually"
Signed-off-by: Aristo Chen <aristo.chen@canonical.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
As this driver needs to use the special sandbox <asm/malloc.h> header
rather than normal malloc, it must be careful of the includes it brings
in. It does not need <spi.h> for anything, so drop it.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
Currently, the phy_config() API is invoked by the driver only once since it
has been probed. While this works in general, it doesn't allow the driver
to bring the PHY back to its default reset state. As a result, the driver
might not be able to recover the PHY from a bad state. To address this,
move phy_config() into the driver's start callback (am65_cpsw_start()).
Apart from providing the means to recover the PHY in the event of failure,
the implementation is in line with the idea of "reset and configure" that
is already followed by am65_cpsw_start() when it comes to programming the
CPSW MAC.
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
The new OSLog region in MTP (firmware 13.3+) persists on handoff to
Linux. To avoid having to come up with some weird DART handoff or DAPF
tricks, let's just steal some of the coprocessor's dedicated SRAM. This
keeps it happy and Linux doesn't need any special handoff then.
Signed-off-by: Hector Martin <marcan@marcan.st>
Signed-off-by: Mark Kettenis <kettenis@openbsd.org>
To be used for special-case oslog support in rtkit-helper.
Signed-off-by: Hector Martin <marcan@marcan.st>
Signed-off-by: Mark Kettenis <kettenis@openbsd.org>
This will work for u-boot itself, but needs a special workaround in the
MTP driver for Linux handoff to work.
Signed-off-by: Hector Martin <marcan@marcan.st>
Signed-off-by: Mark Kettenis <kettenis@openbsd.org>
This driver handles the MTP ASC coprocessor, which does not need any
special handling on the RTKit side and communicates out-of-band.
Signed-off-by: Hector Martin <marcan@marcan.st>
Signed-off-by: Mark Kettenis <kettenis@openbsd.org>
For devices without specific buffer methods, just assume we can give
them raw memory pointers when they request a buffer.
Signed-off-by: Hector Martin <marcan@marcan.st>
Signed-off-by: Mark Kettenis <kettenis@openbsd.org>
We have improvements to the reliability of H6 and H616 DRAM
initialisation, hopefully avoiding those occasional size misdetections
many people reported before.
Also there is some modernisation of the USB PHY code, to use DT provided
regulators and GPIOs, instead of relying on this being badly duplicated
in Kconfig. This also happens to fix broken USB operations for older
boards (using the A20 SoCs, for instance), which were clashing over
grabbing some GPIOs, leading to a driver bailout. There is also some
rework of the H6/H616 SPL clock code, to prepare it for being reused by
the upcoming Allwinner A523 support. This drops the usage of C structs
to model MMIO register frames, and replaces them by using an addition of
the base address with a macro defined offset. Also in preparation for
A523 there is one fix and one addition for the FEL code, to prepare for
the GICv3 interrupt controller that the new SoC uses. And since this is
a simple fix, and was ready, there is also the watchdog driver for that
new SoC. Finally tossing in an easy fix to some H616 defconfig files to
enable eMMC.
I also use the opportunity to enable proper page table protection
(observing read-only and no-execute attributes), support for which the
arm64 port recently gained. I didn't spot any issues on my arm64 board
tests, but it can be easily disabled or backed out again in case any
issues arise.
Full support for the two new SoC series (A133 and A523) we are working
on is not quite ready yet, but might follow still a bit later if
progress permits.
CI passed, and boot-tested on at least one board with a H616, H6, A64,
H3, A20, T113s.
With the SPL clock code and the DRAM init routine we converted all users
of the H6 class "struct sunxi_prcm_reg" over to use #define'd register
offsets now.
Drop the whole definition of this struct now, since it's not needed
anymore, for all H6 and H616 boards.
This removes the entire fragile and questionable definition, and allows
new SoCs to share the code more easily.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
The Allwinner H6 and H616 DRAM initialisation code uses a complex C
struct, modelling the PRCM clock register frame. For those SoCs, this
struct contains 20 registers, but the DRAM code only uses two of them.
Since we want to get rid of this struct, drop the usage of the struct in
the H6 and H616 DRAM code, by using #define'd register names and their
offset, and then adding those names to the base pointer.
This removes one more user of the PRCM clock register struct.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
U-Boot drivers often revert to using C structures for modelling hardware
register frames. This creates some problems:
- A "struct" is a C language construct to group several variables
together. The details of the layout of this struct are partly subject
to the compiler's discretion (padding and alignment).
- The "packed" attribute would force a certain layout, but we are not
using it.
- The actual source of information from the data sheet is the register
offset. Here we create an artificial struct, carefully tuning the
layout (with a lot of reserved members) to match that offset. To help
with correctness, we put the desired information as a *comment*,
though this is purely for the human reader, and has no effect on the
generated layout. This sounds all very backwards.
- Using a struct suggests we can assign a pointer and then access the
register content via the members. But this is not the case, instead
every MMIO register access must go through specific accessor functions,
to meet the ordering and access size guarantees the hardware requires.
- We share those structs in code shared across multiple SoC families,
though most SoCs define their own version of the struct. Members must
match in their name, across every SoC, otherwise compilation will fail.
We work around this with even more #ifdefs in the shared code.
- Some SoCs have an *almost* identical layout, but differ in a few
registers. This requires hard to maintain #ifdef's in the struct
definition.
- Some of the register frames are huge: the H6 CCU device defines 127
registers. We use 15 of them. Still the whole frame would need to be
described, which is very tedious, but for no reason.
- Adding a new SoC often forces people to decide whether to share an
existing struct, or to create a new copy. For some cases (say like 80%
similarity) this works out badly either way.
The Linux kernel heavily frowns upon those register structs, and instead
uses a much simpler solution: #define REG_NAME <offset>
This easily maps to the actual information from the data sheet, and can
much simpler be shared across multiple SoCs, as it allows to have all
SoC versions visible, so we can use C "if" statements instead of #ifdef's.
Also it requires to just define the registers we need, and we can use
alternative locations for some registers much more easily.
Drop the usage of "struct sunxi_prcm_reg" in the H6 SPL clock code, by
defining the respective register names and their offsets, then adding
them to the base pointer.
We cannot drop the struct definition quite yet, as it's also used in
other drivers, still.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
