BCDMA can be used at SPL for OSPI boot and mem-to-mem DMA
so add "bootph-all" to BCDMA node.
Suggested-by: Nishanth Menon <nm@ti.com>
Fixes: 9a3f2b6798 ("arm: dts: k3-am625-verdin-wifi-dev-u-boot.dtsi: Fix DMA/Ethernet")
Signed-off-by: Roger Quadros <rogerq@kernel.org>
Reviewed-by: Nishanth Menon <nm@ti.com>
Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Change spl_enable_dcache so it also enable icache on SPL
initialization for the main domain part of the boot flow. This
improves bootloader booting time.
Link: https://lore.kernel.org/all/20231109140958.1093235-1-joao.goncalves@toradex.com/
Signed-off-by: Joao Paulo Goncalves <joao.goncalves@toradex.com>
Tested-by: Nishanth Menon <nm@ti.com>
main_timer0 is used by u-boot as the tick-timer. Add it to the soc
devices list so it an be enabled via the k3 power controller.
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
BeagleBoard.org BeagleBone AI-64 is an open source hardware single
board computer based on the Texas Instruments TDA4VM SoC featuring
dual-core 2.0GHz Arm Cortex-A72 processor, C7x+MMA and 2 C66x
floating-point VLIW DSPs, 3x dual ARM Cortex-R5 co-processors,
2x 6-core Programmable Real-Time Unit and Industrial Communication
SubSystem, PowerVR Rogue 8XE GE8430 3D GPU. The board features 4GB
DDR4, USB3.0 Type-C, 2x USB SS Type-A, miniDisplayPort, 2x 4-lane
CSI, DSI, 16GB eMMC flash, 1G Ethernet, M.2 E-key for WiFi/BT, and
BeagleBone expansion headers.
This board family can be indentified by the BBONEAI-64-B0 in the
at24 eeprom:
[aa 55 33 ee 01 37 00 10 2e 00 42 42 4f 4e 45 41 |.U3..7....BBONEA|]
[49 2d 36 34 2d 42 30 2d 00 00 42 30 30 30 37 38 |I-64-B0-..B00078|]
Baseline of the devicetree is from v6.6-rc1
https://beagleboard.org/ai-64https://git.beagleboard.org/beagleboard/beaglebone-ai-64
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Move the omap3 beagle to the beagle vendor folder representing
BeagleBoard.org platforms.
Suggested-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Move beagleplay support away from ti/am62x to it's own beagle vendor
folder.
This forms the starting point for new beagle platforms added under it's
own board vendor folder.
As part of this create all the associated files with a bare minimum
beagleplay.c file.
Suggested-by: Andrew Davis <afd@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Bryan Brattlof <bb@ti.com>
[trini: Update k3-binman.dtsi to use full path to scheme.yaml now]
Signed-off-by: Tom Rini <trini@konsulko.com>
With the upcoming folder separation, there is no further need to depend
on am625-binman.dtsi. Duplicate the existing definitions to u-boot.dtsi
and r5.dts as appropriate.
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Bryan Brattlof <bb@ti.com>
Commit 5019170970 ("arch: arm: mach-k3: j721e: add support for UDA
FS") introduced basic UDA FS support, however, we can Take approach
similar to commit 0f1c1e8b36 ("arm: mach-k3: am625: Add support for
UDA FS"). While boot partition support with EMMC boot is useful, it is
constrained by the size of boot hardware partition itself.
In the case of K3 devices, tispl images can contain OP-TEE images that
can substantially vary in size and the u-boot image itself can vary over
time as we enable various features.
So use the CSD information in the case of EMMC_BOOT configuration being
enabled to pick boot partition or UDA FS mode operation to pick.
If EMMC_BOOT is disabled, then depend on filesystem configuration to
pick data from UDA.
Signed-off-by: Nishanth Menon <nm@ti.com>
Enable SOC_K3_J721E_J7200 when board is J7200 EVM - this allows us to
differentiate J7200 platform cleanly in board independent codebase.
Signed-off-by: Nishanth Menon <nm@ti.com>
J7200 shares quite a few characteristics with J721E. However a few sets
are different. Introduce a Kconfig to differentiate the two to allow for
new boards to be introduced in a seamless manner.
Signed-off-by: Nishanth Menon <nm@ti.com>
This file is used to emulate customer keys on TI development board
ecosystems, move it out of board/ directory and into mach-k3. And
change the relative paths to absolute paths in the binman paths.
While at it, drop the reference in verdin-binman file which is
redundant.
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Acked-by: Manorit Chawdhry <m-chawdhry@ti.com>
This file is common for all of K3, move it out of board/ directory and
into mach-k3. And change the relative paths to absolute paths in the
binman paths.
While at it, drop the reference in verdin-binman file which is
redundant.
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Reviewed-by: Andrew Davis <afd@ti.com>
SYSFW is only ever loaded by the R5 core, move the code into that
directory. While here also move the related Kconfig symbols.
Signed-off-by: Andrew Davis <afd@ti.com>
The kconfig option SPL means this build supports SPL but not that
this build is SPL, nor that this build is the SPL running on R5.
For options that are for R5 SPL use CPU_V7R.
Signed-off-by: Andrew Davis <afd@ti.com>
This makes it clear these are only to be used by the R5 builds of SPL.
And this will be used to later more cleanly split the two builds.
Signed-off-by: Andrew Davis <afd@ti.com>
Currently each set of board targets from a vendor is selected inside
the board directory for that vendor. This has the problem of multiple
targets, one from each vendor, being selectable at the same time.
For instance you can select both TARGET_AM654_A53_EVM and
TARGET_IOT2050_A53 in the same build.
To fix this we need to move the target board choice to a common location
for each parent SoC selection. Do this in arch/arm/mach-k3.
Signed-off-by: Andrew Davis <afd@ti.com>
Currently each set of board targets from a vendor is selected inside
the board directory for that vendor. This has the problem of multiple
targets, one from each vendor, being selectable at the same time.
For instance you can select both TARGET_AM654_A53_EVM and
TARGET_IOT2050_A53 in the same build.
To fix this we need to move the target board choice to a common location
for each parent SoC selection. Do this in arch/arm/mach-k3.
Signed-off-by: Andrew Davis <afd@ti.com>
Currently each set of board targets from a vendor is selected inside
the board directory for that vendor. This has the problem of multiple
targets, one from each vendor, being selectable at the same time.
For instance you can select both TARGET_AM654_A53_EVM and
TARGET_IOT2050_A53 in the same build.
To fix this we need to move the target board choice to a common location
for each parent SoC selection. Do this in arch/arm/mach-k3.
Signed-off-by: Andrew Davis <afd@ti.com>
Currently each set of board targets from a vendor is selected inside
the board directory for that vendor. This has the problem of multiple
targets, one from each vendor, being selectable at the same time.
For instance you can select both TARGET_AM654_A53_EVM and
TARGET_IOT2050_A53 in the same build.
To fix this we need to move the target board choice to a common location
for each parent SoC selection. Do this in arch/arm/mach-k3.
Signed-off-by: Andrew Davis <afd@ti.com>
Currently each set of board targets from a vendor is selected inside
the board directory for that vendor. This has the problem of multiple
targets, one from each vendor, being selectable at the same time.
For instance you can select both TARGET_AM654_A53_EVM and
TARGET_IOT2050_A53 in the same build.
To fix this we need to move the target board choice to a common location
for each parent SoC selection. Do this in arch/arm/mach-k3.
Signed-off-by: Andrew Davis <afd@ti.com>
Currently each set of board targets from a vendor is selected inside
the board directory for that vendor. This has the problem of multiple
targets, one from each vendor, being selectable at the same time.
For instance you can select both TARGET_AM654_A53_EVM and
TARGET_IOT2050_A53 in the same build.
To fix this we need to move the target board choice to a common location
for each parent SoC selection. Do this in arch/arm/mach-k3.
Signed-off-by: Andrew Davis <afd@ti.com>
This reverts commit 6cdf6b7a34. This is
part of a series trying to make use of the arm64 hardware features for
tracking dirty pages. Unfortunately this series causes problems for the
AC5/AC5X SoCs. Having exhausted other options the consensus seems to be
reverting this series is the best course of action.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
This reverts commit 836b8d4b20. This is
part of a series trying to make use of the arm64 hardware features for
tracking dirty pages. Unfortunately this series causes problems for the
AC5/AC5X SoCs. Having exhausted other options the consensus seems to be
reverting this series is the best course of action.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
This reverts commit c1da6fdb5c. This is
part of a series trying to make use of the arm64 hardware features for
tracking dirty pages. Unfortunately this series causes problems for the
AC5/AC5X SoCs. Having exhausted other options the consensus seems to be
reverting this series is the best course of action.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
This fixes a regression in the eMMC fast boot mode case where the buffer
was missing 464 bytes.
The code figures out how many bytes must at least be fetched to honor
the current read, rounds that up to the ss->pagesize [which is a no-op
in the USB download case because that has ->pagesize==1], fetches that
many bytes, but then recorded the original upper bound as the new end of
the valid data. However, this did not take into account the rounding up
to the ss->pagesize. Fix this by recording the actual bytes downloaded.
Fixes: 4b4472438f ("imx: spl_imx_romapi: avoid tricky use of spl_load_simple_fit() to get full FIT size")
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Acked-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Aligning addresses and sizes causes overhead which is unnecessary when we
are not loading from block devices. Remove bl_len when it is not needed.
For example, on iot2050 we save 144 bytes with this patch (once the rest of
this series is applied):
add/remove: 0/0 grow/shrink: 0/3 up/down: 0/-144 (-144)
Function old new delta
spl_load_simple_fit 920 904 -16
load_simple_fit 496 444 -52
spl_spi_load_image 384 308 -76
Total: Before=87431, After=87287, chg -0.16%
We use panic() instead of BUILD_BUG_ON in spl_set_bl_len because we still
need to be able to compile it for things like mmc_load_image_raw_sector,
even if that function will not be used.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
For filesystems, filename serves the same purpose as priv. However,
spl_load_fit_image also uses it to determine whether to use a DMA-aligned
buffer. This is beneficial for FAT, which uses a bounce-buffer if the
destination is not DMA-aligned. However, this is unnecessary now that
filesystems set bl_len to ARCH_DMA_MINALIGN instead. With this done, we can
remove filename entirely.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Simplify things a bit for callers of spl_load_info->read by refactoring it
to use units of bytes instead of bl_len. This generally simplifies the
logic, as MMC is the only loader which actually works in sectors. It will
also allow further refactoring to remove the special-case handling of
filename. spl_load_legacy_img already works in units of bytes (oops) so it
doesn't need to be changed.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Remove NULL assignments to fields in spl_load_info when .load doesn't
reference these fields. This can result in more efficient code. filename
must stay even if it is unused, since load_simple_fit uses it.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Several AT91 boards are quite close to their SPL size limit. For example,
sama5d27_wlsom1_ek_mmc is just 173 bytes short of its limit and doesn't
even fit with older GCCs.
All AT91 processors should have thumb support. Enable SYS_THUMB_BUILD. This
shrinks SPL by around 30%.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Add initial support for STM32MP2 SoCs family.
SoCs information are available here :
https://www.st.com/content/st_com/en/campaigns/microprocessor-stm32mp2.html
Migrate all MP1 related code into stm32mp1/ directory
Create stm32mp2 directory dedicated for STM32MP2 SoCs.
Common code to MP1, MP13 and MP25 is kept into
arch/arm/mach-stm32/mach-stm32mp directory :
- boot_params.c
- bsec
- cmd_stm32key
- cmd_stm32prog
- dram_init.c
- syscon.c
- ecdsa_romapi.c
For STM32MP2, it also :
- adds memory region description needed for ARMv8 MMU.
- enables early data cache before relocation.
During the transition before/after relocation, the MMU, initially setup
at the beginning of DDR, must be setup again at a correct address after
relocation. This is done in enables_caches() by disabling cache, force
arch.tlb_fillptr to NULL which will force the MMU to be setup again but
with a new value for gd->arch.tlb_addr. gd->arch.tlb_addr has been
updated after relocation in arm_reserve_mmu().
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Add STM32MP257F Evaluation board support. It embeds a STM32MP257FAI SoC,
with 4GB of DDR4, TSN switch (2+1 ports), 2*USB typeA, 1*USB2 typeC,
SNOR OctoSPI, mini PCIe, STPMIC2 for power distribution ...
Sync device tree with kernel v6.6-rc1.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
When building with AARCH64 defconfig, we got warnings, fix them.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Limit DDR usage under 4GB boundary on STM32MP regardless of
memory size declared in device tree.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
When building with AARCH64 defconfig, we got warnings for debug
message
- format '%x' expects argument of type 'unsigned int',
but argument 3 has type 'size_t' {aka 'long unsigned int'}).
- format '%lx' expects argument of type 'long unsigned int',
but argument 2 has type 'phys_addr_t' {aka 'long long unsigned
int'}
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
In case there is no RAM driver retrieve RAM size from DT as fallback.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
This fixes the following compilation error in ARM64:
arch/arm/mach-stm32mp/dram_init.c: In function ‘board_get_usable_ram_top’:
arch/arm/mach-stm32mp/dram_init.c:59:45: error: ‘DCACHE_DEFAULT_OPTION’ undeclared (first use in this function)
59 | mmu_set_region_dcache_behaviour(reg, size, DCACHE_DEFAULT_OPTION);
| ^~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
The sysreset uclass unconditionally provides a definition of the
reset_cpu() function. So does the exynos soc code. Fix the build with
SYSRESET enabled by omitting the function from the soc code in that
case. The code still needs to be kept around for use in SPL.
This commit was inspired by commit 6e19dc84c1 ("sunxi: Avoid duplicate
reset_cpu with SYSRESET enabled").
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
arch/arm/include/asm/arch/gpio.h relies on definitions from cpu.h.
Include it explicitly in gpio.h. Otherwise next build error may occur:
In file included from ./arch/arm/include/asm/gpio.h:7,
from include/cros_ec.h:14,
from board/samsung/common/board.c:8:
./arch/arm/include/asm/arch/gpio.h:1357:4:
error: 'EXYNOS4_GPIO_PART1_BASE' undeclared here
(not in a function); did you mean 'EXYNOS4_GPIO_MAX_PORT'?
1357 | { EXYNOS4_GPIO_PART1_BASE, EXYNOS4_GPIO_MAX_PORT_PART_1 },
| ^~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
samsung_get_base_swreset() is called in soc.c, but corresponding header
with its prototype is not included. Fix this to avoid possible build
errors.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
The H616 SoC family has support for several types of DRAM: DDR3,
LPDDR3, DDR4 and LPDDR4.
At the moment, the driver only supports DDR3 and LPDDR3 memory.
Let's extend the driver to support the LPDDR4 memory. This type
of memory widely used in device with T507(-H) SoC and new orangepi
zero3 with H618.
The compatibility with T507 is not yet complete, because there
is difference in the phy_init array.
The LPDDR4-2133 timings correspond to DRAM Rayson RS1G32LO4D2BDS-53BT
found on the NOR SPI from the Orangepi Zero 3 4GB.
Signed-off-by: Mikhail Kalashnikov <iuncuim@gmail.com>
Tested-by: Piotr Oniszczuk <piotr.oniszczuk@gmail.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Acked-by: Andre Przywara <andre.przywara@arm.com>
The original H616 DDR3 ODT configuration code wrote board specific values
into a sequence of paired registers.
For LPDDR3 support we needed to special-case one group of registers,
because for that DRAM type we need to write 0 into the lower register of
each pair. That already made the code less readable.
LPDDR4 support will make things even messier, so let's refactor that
code now: We allow to write different values into the lower and upper
half of each pair. The masking is moved into a macro, and use in each
write statement.
The effect is not as obvious yet, as we don't need the full flexibility at
the moment, but the motivation will become clearer with LPDDR4 support.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Reviewed-by: Mikhail Kalashnikov <iuncuim@gmail.com>
On boards using the AXP313 PMIC, the DRAM rail is often not setup
correctly at reset time, so we have to program the PMIC very early in
the SPL, before running the DRAM initialisation.
Add a simple AXP313 PMIC driver that knows about DCDC2(CPU) and
DCDC3(DRAM), so that we can bump up the voltage before the DRAM init.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
The MMC controller driver is (and ought to be) the only user of these
register definitions. Put them in a header next to the driver to remove
the dependency on a specific ARM platform's headers.
Due to the sunxi_mmc_init() prototype, the file was not renamed. None of
the register definitions were changed.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
To quote the author:
Since commit [1], Ethernet is broken on TI AM62 and AM64 platforms.
The commit [1] is not the culprit. It just unearths the problem by fixing
the error check in k3-udma.c. This issue was silently being ignored earlier
due to wrong error check. [NULL instead of FDT_ADDR_T_NONE].
Fix the issue by adding the necessary register spaces for the u-boot K3-UDMA
driver for AM62 and AM64 platforms.
These properties will eventually make it into the SoC DTSi files [2] after
which these can be dropped from k3-*-u-boot.dtsi files.
[1] - 5fecea171de3dd ("treewide: use dev_read_addr_*_ptr() where appropriate")
[2] - https://lore.kernel.org/linux-arm-kernel/20230810174356.3322583-1-vigneshr@ti.com/
Update main_bcdma and main_pktdma nodes for native configuration in the
absence of DM services.
Drop duplicate main_pktdma node in k3-am642-sk-u-boot.dtsi.
Reported-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Signed-off-by: Roger Quadros <rogerq@kernel.org>
Reviewed-by: Nishanth Menon <nm@ti.com>
Update main_bcdma and main_pktdma nodes for native configuration in the
absence of DM services.
Reported-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Signed-off-by: Roger Quadros <rogerq@kernel.org>
Reviewed-by: Nishanth Menon <nm@ti.com>
Add support for a semihosting fallback on 32-bit ARM. The assembly is
lightly adapted from the irq return code, except there is no offset
since lr already points to the correct instruction. The C side is mostly
like ARM64, except we have fewer cases to deal with.
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
U-Boot runs in supervisor mode. On ARMv6 and lower, software interrupts
are taken in supervisor mode. When entering an interrupt, the link
register is set to the address of the next instruction. However, if we
are already in supervisor mode, this clobbers the link register. The
debugger can't help us, since by the time it notices we've taken a
software interrupt, the link register is already gone. Work around this
by moving the return address to another register.
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
When we take a software interrupt, we are already in supervisor mode.
get_bad_stack assumes we are not in supervisor mode so it can clobber
the stack pointer. This causes us to have an invalid stack once that
macro finishes. Revert back to the get_bad_stack_swi macro which was
previously removed.
Fixes: 41623c91b0 ("arm: move exception handling out of start.S files")
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
_ Fix compilation issue when SYS_DCACHE_OFF and/or SYS_DCACHE_SYS are enabled
_ Fix issue following DT sync with kernel 6.3 for stm32mp15xx-ev1 and DHSOM SoM
_ Enable TCP, IPv6, wget on DH STM32MP15 DHSOM
_ Limit u-boot.itb size to 0x160000 bytes on DH STM32MP15 DHSOM
_ Read auth stats and boot_partition from tamp
- Fix some issues Coverity has reported, update MAINTAINERS file,
another bootstd fix, typo fix in error message, gitignore fix and
update TI's URL in many places.
Keep track of the re-entries with help of the lr register.
This binary can be re-used and called from various BROM functions.
Only when it's called from the part that handles SPI, NAND or EMMC
hardware it needs to early return to BROM ones.
In download mode when it handles data on USB OTG and UART0
this section must be skipped.
Unlike newer Rockchip SoC models the rk3066 BROM code does not have built-in
support to enter download mode on return to BROM. This binary must check
the boot mode register for the BOOT_BROM_DOWNLOAD flag and reset if it's set.
It then returns to BROM to the end of the function that reads boot blocks.
From there the BROM code goes into a download mode and waits for data
on USB OTG and UART0.
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Provide configuration to read cpuid and generate a persistent
MAC address in ethaddr
Signed-off-by: Tim Lunn <tim@feathertop.org>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
RV1126 fails to boot on 2024.01-rc1.
Commit 9e644284ab ("dm: core: Report bootph-pre-ram/sram node as
pre-reloc after relocation") changed the behaviour of bootph-pre-ram, to
limit nodes to spl phase. This caused rv1126 boards to fail to boot with
the current dts.
This patch updates the pmu/grf nodes to bootph-all tags as they are
needed in all phases. This fixes the boot issue on rv1126 boards.
Signed-off-by: Tim Lunn <tim@feathertop.org>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Obtain from TAMP backup register information about image authorization
status and partition id used for booting. Store this info in
environmental variables ("boot_auth" and "boot_part" correspondingly).
Image authorization supported values:
0x0 - No authentication done
0x1 - Authentication done and failed
0x2 - Authentication done and succeeded
These values are stored to TAMP backup register by Trusted Firmware-A [1].
Testing:
STM32MP> print boot_part
boot_part=1
STM32MP> print boot_auth
boot_auth=2
[1] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?h=refs/heads/integration&id=ab2b325c1ab895e626d4e11a9f26b9e7c968f8d8
Signed-off-by: Igor Opaniuk <igor.opaniuk@foundries.io>
Co-developed-by: Oleksandr Suvorov <oleksandr.suvorov@foundries.io>
Signed-off-by: Oleksandr Suvorov <oleksandr.suvorov@foundries.io>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
The patch fixed by this commit renders ST STM32MP15xx EV1 board and
all DHSOM SoM based boards unbootable from SPI NOR. Fix the damage
by updating -u-boot.dtsi to match the stm32mp15-pinctrl.dtsi update.
Fixes: 08002ffd08 ("ARM: dts: stm32mp: alignment with v6.3")
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
While 23e20b2fa6 ("arm: stm32mp: Fix compilation issue when
SYS_DCACHE_OFF and/or SYS_DCACHE_SYS are enabled") tried fixing
this issue, fix it really by adding #if checks for SYS_ICACHE_OFF
and SYS_DCACHE_OFF.
Cc: Patrice Chotard <patrice.chotard@foss.st.com>
Cc: Patrick Delaunay <patrick.delaunay@foss.st.com>
Signed-off-by: Bhupesh Sharma <bhupesh.sharma@linaro.org>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
QuartzPro64 is a Rockchip RK3588 based SBC by Pine64.
UART and boot over SD/eMMC/RJ45 are tested to work.
Linux commits from next-20231013:
8152d3d070a9 ("arm64: dts: rockchip: Add QuartzPro64 SBC device tree")
Signed-off-by: Tom Fitzhenry <tom@tom-fitzhenry.me.uk>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Cc: Eugen Hristev <eugen.hristev@collabora.com>
Cc: Jonas Karlman <jonas@kwiboo.se>
Cc: Ondrej Jirman <megi@xff.cz>
The migration deadline for moving to DM_SCSI was v2023.04. A further
reminder was sent out in August 2023 to the remaining platforms that had
not migrated already, and that a few more over the line (or configs
deleted).
With this commit we:
- Rename CONFIG_DM_SCSI to CONFIG_SCSI.
- Remove all of the non-DM SCSI code. This includes removing other
legacy symbols and code and removes some legacy non-DM AHCI code.
- Some platforms that had previously been DM_SCSI=y && SCSI=n are now
fully migrated to DM_SCSI as a few corner cases in the code assumed
DM_SCSI=y meant SCSI=y.
Signed-off-by: Tom Rini <trini@konsulko.com>
The include <asm/arch/cpu.h> references values in <asm/arch/omap3.h> and
so include it directly here rather than rely on indirect inclusion.
Signed-off-by: Tom Rini <trini@konsulko.com>
Xilinx is using standard mtd partition layout for quite a long time. It is
used for testing purpose on evaluation boards.
Also #address/size-cells shouldn't be present without nodes which should
use them that's why move them from zynq-7000.dtsi to nand/nor nodes
directly.
The patch was tested on zc706 and zedboard(with also increasing max
frequency and rx bus width).
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/4c3348981bba32d3892194420d78fe8621c47534.1698837725.git.michal.simek@amd.com
SMMU is disabled by default and not all masters can be enabled at the same
time because of limited number of entries. That's why comment all iommu
properties but keep them for reference in DT. In XEN case they should be
added back and Xen should have SMMU enabled by default.
Also add IDs for DP and DPDMA.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/e868c27c52ded5d8ef25f75ba394b1ab3b31b80a.1698825657.git.michal.simek@amd.com
Mini U-Boot is running out of OCM and it's only purpose is to program non
volatile memories. There are different configurations which ospi/qspi can
be that's why describe them via DT.
DT binding is already approved that's why there is no reason not to add it.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/a99a8d72201a782fc811715942dea97fb5ab583b.1698329087.git.michal.simek@amd.com
Mini U-Boot is running out of OCM and it's only purpose is to program non
volatile memories. There are different configurations which ospi/qspi can
be that's why describe them via DT.
DT binding is already approved that's why there is no reason not to add it.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/9518ab1c4299a45e800b8611172edd78c9243132.1698329087.git.michal.simek@amd.com
Mini U-Boot is running out of OCM and it's only purpose is to program non
volatile memories. There are different configurations which qspi can be
that's why describe them via DT.
DT binding is already approved that's why there is no reason not to add it.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/e7d31a9d9c4a76e171eefc619f31fabd0831a614.1698329087.git.michal.simek@amd.com
Mini U-Boot is running out of OCM and it's only purpose is to program non
volatile memories. There are different configurations which qspi can be
that's why describe them via DT.
DT binding is already approved that's why there is no reason not to add it.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/28b3cdd7e91b2b4c3c36d0bf65aa5bac042f248c.1698329087.git.michal.simek@amd.com
gpio38 is used in SOM's kv260 to reset the Ethernet PHY.
At present, HW reset is not working properly as Tri-state
is enabled for MIO38, causing inappropriate PHY register reads.
Disabled Tri-state for MIO38 to make HW reset work.
Tri-state disable :
ZynqMP> md 0xFF180208 2
ff180208: 00bfe7a3 00000540
Tri-state enable :
ZynqMP> md 0xFF180208 2
ff180208: 00bfe7e3 00000540
Signed-off-by: Tejas Bhumkar <tejas.arvind.bhumkar@amd.com>
Link: https://lore.kernel.org/r/20231020050622.972750-1-tejas.arvind.bhumkar@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
Board specific late init allows vendors to set up different device
or board specific env variables (like serial number, platform name).
In case this information is missing, u-boot will lack info regards
serial or platform.
To avoid this prior nvidia_board_late_init internal generic function
is called which fills required data. In this case platform name is
obtained from get_chip and serialno is filled with SoC id.
Though SoC id is not dedicated to be devices serial but it fits well
in case of restriction of data about device and since SoC is basically
a main chip of the device.
Tested-by: Andreas Westman Dorcsak <hedmoo@yahoo.com> # ASUS Transformers
Tested-by: Svyatoslav Ryhel <clamor95@gmail.com> # Nvidia Tegratab
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Re-crypt support was extended to devices without burnt SBK. In case
SBK is not set, place from where it is read is filled with zeroes.
This patch adds support for ebtupdate function to detect nosbk device
and avoid crypto operations for it.
Tested-by: Maksim Kurnosenko <asusx2@mail.ru>
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Tegra 4, same as Tegra 3, requires configuration of CPU and CORE
voltages in the SPL stage to boot properly. Expose function to be
able perform this configuration in the SPL section of the device
board.
Tested-by: Svyatoslav Ryhel <clamor95@gmail.com> # ASUS TF701T
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
TF201 unlike other transformers uses non-fused xcvr value for
its dock USB port. With out it dock USB and SD reader will not
work.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
TF600T has significant differences (Tegra DSI and DSI panel,
own power supply system) which makes use of common transformer
device tree complicated.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
P1801-T has significant differences (hdmi panel and backlight,
own power supply system) which makes use of common transformer
device tree complicated.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Default-tap and default-trim values are used for eMMC setup
mostly on T114+ devices. As for now, those values are hardcoded
for T210 and ignored for all other Tegra generations. Fix this
by passing tap and trim values from dts.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Tegra MMC driver has hardcoded tap and trim values as for now.
Set default-tap and default-trim values in sdhci nodes to avoid
regressions in case Tegra MMC driver is upated to use dts values.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
For most source files we can just drop <common.h>. We need to add an
include for <asm/u-boot.h> in a couple of places. Also sort the include
list in memmap-gen3.c while we're here.
Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com>
If <common.h> won't be included before <asm/armv8/mmu.h>, we need to
ensure that we have the required type definitions.
Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Similar change was done by commit b4c2c151b1 ("Kconfig: Remove all
default n/no options") and again sync is required.
default n/no doesn't need to be specified. It is default option anyway.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Reviewed-by: Svyatoslav Ryhel <clamor95@gmail.com> # tegra
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Angelo Dureghello <angelo@kernel-space.org>
Disarm the error message forcing u-boot/spl image to be located at
sector 0 on eMMC data-partition and microSD.
Offset 0 makes sense on eMMC boot partitions only, data partition must
use 4096 to avoid conflicting with MBR.
Valid offsets when booting from microSD, reported by boot-rom v1.73:
BootROM: Bad header at offset 00000200
BootROM: Bad header at offset 00004400
BootROM: Bad header at offset 00200000
BootROM: Bad header at offset 00400000
BootROM: Bad header at offset 00600000
BootROM: Bad header at offset 00800000
BootROM: Bad header at offset 00A00000
BootROM: Bad header at offset 00C00000
BootROM: Bad header at offset 00E00000
BootROM: Bad header at offset 01000000
BootROM: Bad header at offset 01200000
BootROM: Bad header at offset 01400000
BootROM: Bad header at offset 01600000
BootROM: Bad header at offset 01800000
BootROM: Bad header at offset 01A00000
BootROM: Bad header at offset 01C00000
BootROM: Bad header at offset 01E00000
BootROM: Bad header at offset 02000000
BootROM: Bad header at offset 02200000
BootROM: Bad header at offset 02400000
BootROM: Bad header at offset 02600000
BootROM: Bad header at offset 02800000
BootROM: Bad header at offset 02A00000
BootROM: Bad header at offset 02C00000
BootROM: Bad header at offset 02E00000
Valid offsets when booting from eMMC:
BootROM: Bad header at offset 00000000
BootROM: Bad header at offset 00200000
Switching BootPartitions.
BootROM: Bad header at offset 00000000
BootROM: Bad header at offset 00200000
Fixes: 2226ca1734 ("arm: mvebu: Load U-Boot proper binary in SPL code based on kwbimage header")
Signed-off-by: Josua Mayer <josua@solid-run.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Extend Turris Mox board code to support CZ.NIC's RIPE Atlas Probe.
Signed-off-by: Marek Behún <kabel@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
- Add Board: rk3588 NanoPC-T6, Orange Pi 5, Orange Pi 5 Plus;
- clk driver fix for rk3568 and rk3588;
- rkmtd cmd support for rockchip nand device;
- dts update and sync from linux;
Xunlong Orange Pi 5 Plus is a single-board computer based on the
Rockchip RK3588 SoC. The board provides abundant interfaces, including
two HDMI output ports, one HDMI input port, two 2.5G Ethernet ports,
M.2 M-Key slot, M.2 E-Key slot, two USB 3.0, two USB 2.0, and two Type-C.
Features tested on a Orange Pi 5 Plus 4GB v1.2:
- SD-card boot
- eMMC boot
- SPI Flash boot
- PCIe/NVMe
- USB 2.0 host
- Ethernet
Device tree is imported from linux v6.7-rockchip-dts64-1 tag.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Xunlong Orange Pi 5 is a single-board computer based on the Rockchip
RK3588S SoC. The board provides abundant interfaces, HDMI output, GPIO
interface, M.2 PCIe2.0, Type-C, Gigabit LAN port, 2*USB2.0, 1*USB3.0,
etc.
Features tested on a Orange Pi 5 4GB v1.2:
- SD-card boot
- SPI Flash boot
- PCIe/NVMe
- USB 2.0 host
- Ethernet
Device tree is imported from linux v6.7-rockchip-dts64-1 tag.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
The device tree for rk3588 and rock-5b contain usb3 nodes that have
deviated too much from current state of submitted mainline linux usb3
patches, see [1].
Sync usb3 related nodes from latest patches and collaboras rk3588 tree
so that dwc3-generic driver can be updated to include support for the
rockchip,rk3588-dwc3 compatible in the future, use rockchip,rk3568-dwc3
compatible until final node is merged in linux maintainer tree.
[1] https://lore.kernel.org/lkml/20231009172129.43568-1-sebastian.reichel@collabora.com/
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
-----BEGIN PGP SIGNATURE-----
iQFQBAABCgA6FiEEqxhEmNJ6d7ZdeFLIHrMeAg6sL8gFAmU2fxwcHGV1Z2VuLmhy
aXN0ZXZAY29sbGFib3JhLmNvbQAKCRAesx4CDqwvyKr+B/42+WkPiAiwt79R6Kh5
UKo404oN1na28D3V12EvikiCH2QWubi38EV7VfcB3jqEpxj4j+rY0cSLZv+u7d4/
bfQN3FPrcTwYnXYLbYkUKC+MAVzGLiVzFBBhIt5cPrT4iVXctwYY6LJ58aX8uRo6
KU6CwXYc3cnmIUqpXE4EYbbQU4TAp55SV2n8QLFFI9DHcy2kELfdrZduFn+Hm9Ij
9sQHH5JxbrGHv5XpcjJkARW3M4K3K4TPzweFGN61VMJwWqzD3L4YPshwIGDfhRui
LECKCdr/rWkavumXCfw2pD3RYFTqnqnUzaEN/3ueL9FCJ2uFH1EyaoSuXFEn3+Ul
m1LE
=CMMd
-----END PGP SIGNATURE-----
Merge tag 'u-boot-at91-2024.01-b' of https://source.denx.de/u-boot/custodians/u-boot-at91
Second set of u-boot-at91 features for the 2024.01 cycle
This feature set a new board named Conclusive KSTR sama5d27 with some
small prerequisites patches.
This is mostly about support for the Allwinner R528/T113s SoC, which is
reportedly the same die as the Allwinner D1, but with the two
Arm Cortex-A7 cores activated instead of the RISC-V one.
Using sunxi code outside of arch/arm proved to be difficult, so apart
from enabling this Arm SoC, the patches also prepare for more refactoring
to get the D1 nicely supported some day:
- We get rid of some Kconfig (hard-)coded GPIO pins, responsible for
enabling regulators.
- The GPIO code is moved out of arch/arm, into drivers/gpio.
- Some definitions are moved out of header files under asm/arch.
- Some T113s/D1 specific definitions are guarded by a generic Kconfig
symbol (CONFIG_SUNXI_GEN_NCAT2).
- The DRAM controller initialisation code is located under drivers/ram.
- The base SoC .dtsi files are shared (under arch/riscv, as in Linux).
Of course there are also the usual new SoC specific patches, like clock
and pinmux descriptions, alongside a rework of the pinctrl code, since
Allwinner changed the GPIO register layout, for the first time since
sunxi's inception.
On top of this the PSCI code sees some update, to provide SMP services
for R528/T113s boards. Many thanks to Sam for providing this code and
staying strong through the review cycles.
The final patch enables support for one popular board, I hope to see
more DTs and defconfigs contributed in the future!
Many thanks to all the various contributors, testers and reviewers,
that series was a real team effort!
Introduce support for Conclusive KSTR-SAMA5D27 Single Board Computer.
Co-developed-by: Jakub Klama <jakub@conclusive.pl>
Signed-off-by: Jakub Klama <jakub@conclusive.pl>
Co-developed-by: Marcin Jabrzyk <marcin@conclusive.pl>
Signed-off-by: Marcin Jabrzyk <marcin@conclusive.pl>
Signed-off-by: Artur Rojek <artur@conclusive.pl>
Sync the rk3328-rock64 dts from v6.6-rc5.
See Linux kernel commit for details:
03633c4ef1fb ("arm64: dts: rockchip: fix USB regulator on ROCK64")
Signed-off-by: Matwey V. Kornilov <matwey.kornilov@gmail.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
The NanoPC-T6 is a Rockchip RK3588 based SBC by FriendlyElec.
There are four variants depending on the DRAM size: 4G/32GB eMMC,
8G/64GB eMMC, 16G/16MB SPI NOR, and 16G/256GB eMMC/16MB SPI NOR
Specifications:
CPU: Rockchip RK3588, 4x Cortex-A76 (up to 2.4GHz)
+ 4x Cortex-A55 (up to 1.8GHz)
GPU: Mali-G610 MP4
VPU: 8K@60fps H.265 and VP9 decoder, 8K@30fps H.264 decoder,
4K@60fps AV1 decoder, 8K@30fps H.264 and H.265 encoder
NPU: 6TOPs, supports INT4/INT8/INT16/FP16
RAM: 64-bit 4GB/8GB/16GB LPDDR4X at 2133MHz
eMMC: 0GB/32GB/64GB/256GB HS400
MicroSD Slot: MicroSD SDR104
PCIe 3.0: M.2 M-Key x1, PCIe 3.0 x4 for NVMe SSDs up to 2,500 MB/s
Ethernet: PCIe 2.5G 2x Ethernet (RTL8125BG)
PCIe 2.1: M.2 E-Key x1, PCIe 2.1 x1 and USB2.0 Host,
supports M.2 WiFi and Bluetooth
4G Module: MiniPCIe x1, MicroSIM Card Slot x1
Audio Out: 3.5mm jack for stereo headphone output
Audio In: 2.0mm PH-2A connector for analog microphone input
Video Input: standard HDMI input port, up to 4Kp60
2x 4-lane MIPI-CSI, compatible with MIPI V1.2
Video Output: 2x standard HDMI output ports compatible with HDMI2.1,
HDMI2.0, and HDMI1.4
2x 4-lane MIPI-DSI, compatible with MIPI DPHY 2.0 or CPHY 1.1
USB-A: USB 3.0, Type A
USB-C: Full function USB Type‑C port, DP display up to 4Kp60, USB 3.0
40-pin 2.54mm header connector: up to 2x SPIs, 6x UARTs, 1x I2Cs,
8x PWMs, 2x I2Ss, 28x GPIOs
Debug UART: 3 Pin 2.54mm header, 3V level, 1500000bps
Onboard IR receiver: 38KHz carrier frequency
RTC Battery: 2 Pin 1.27/1.25mm RTC battery connector for low power
RTC IC HYM8563TS
5V Fan connector
Working Temperature: 0C to 70C
Power: 5.5*2.1mm DC Jack, 12VDC input
Dimensions: 110x80x1.6mm (without case) / 86x114.5x30mm (with case)
Kernel commits:
893c17716d0c ("arm64: dts: rockchip: Add NanoPC T6")
a721e28dfad2 ("arm64: dts: rockchip: Add NanoPC T6 PCIe Ethernet support")
ac76b786cc37 ("arm64: dts: rockchip: Add NanoPC T6 PCIe e-key support")
Signed-off-by: John Clark <inindev@gmail.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Enable mini PCIe slot, pcie3x1 node, now that the PCIe PHY driver
support bifurcation.
A pinctrl is assigned for reset-gpios or the device may freeze running
pci enum and nothing is connected to the mini PCIe slot.
Also drop the AHCI_PCI Kconfig option as this option is not required for
a functional M.2 SATA drive slot.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
The MangoPi MQ-R board uses an Allwinner T113s Soc (with 128MB of
embedded DRAM), support for which was just added to the code.
Since the devicetree was already synced from the latest Linux kernel
tree, all we need is a _defconfig file to add support for the board.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
This patch adds the necessary code to make nonsec booting and PSCI
secondary core management functional on the R528/T113.
Signed-off-by: Sam Edwards <CFSworks@gmail.com>
Tested-by: Maksim Kiselev <bigunclemax@gmail.com>
Tested-by: Kevin Amadiva <kevin.amadiva@mec.at>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Since the sunxi support nowadays generally prefers #defined register
offsets instead of modeling register layouts using C structs, now is a
good time to do this for PSCI as well. This patch moves away from using
the structs `sunxi_cpucfg_reg` and `sunxi_prcm_reg` in psci.c.
The former struct and its associated header file existed only to support
PSCI code, so also delete them altogether.
Signed-off-by: Sam Edwards <CFSworks@gmail.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
This is to prepare for R528, which does not have the typical
"CPUCFG" block; it has a "CPUX" block which provides these
same functions but is organized differently.
Moving the hardware-access bits to their own functions separates the
logic from the hardware so we can reuse the same logic.
Signed-off-by: Sam Edwards <CFSworks@gmail.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
This patch restructures psci.c to get away from the "many different
function definitions switched by #ifdef" paradigm to the preferred style
of having a single function definition with `if (IS_ENABLED(...))` to
make the optimizer include only the appropriate function bodies instead.
There are no functional changes here.
Signed-off-by: Sam Edwards <CFSworks@gmail.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
At the moment we have each SoC's memory map defined in its own cpu.h,
which is included in include/configs/sunxi_common.h. This will be a
problem with the introduction of Allwinner RISC-V support.
Remove the inclusion of that header file from the common config header,
instead move the required serial base addresses (for the SPL) into a
separate header file. Then include the original cpu.h file only where
we really need it, which is only under arch/arm now.
This disentangles the architecture specific header files from the
generic code.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
This adds the remaining code bits to teach U-Boot about Allwinner's
newest SoC generation. This was introduced with the RISC-V based
Allwinner D1 SoC, which actually shares a die with the ARM cores versions
called R528 (BGA, without DRAM) and T113s (QFP, with embedded DRAM).
This adds the new Kconfig stanza, using the two newly introduced symbols
for the new SoC generation and pincontroller. It also adds the new symbols
to the relavent code places, to set all the hardcoded bits directly.
We need one DT override:
The ARM core version of the DT specifies the CPUX watchdog as
"reserved", which means it won't be recognised by U-Boot. Override this
in our generic sunxi-u-boot.dtsi, to let U-Boot pick up this watchdog,
so that the generic reset driver will work.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
The PLL_PERIPH0 clock changed a bit in the D1/R528/T113s SoCs: there is
new P0 divider at bits [18:16], and the M divider is 1.
Add code to support this version of "PLL6".
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
The D1/R528/T113s SoCs introduce a new "LDO enable" bit in the CPUX_PLL.
Just enable that when we program that PLL.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Allwinner seems to typically stick to a common MMIO memory map for
several SoCs, but from time to time does some breaking changes, which
also introduce new generations of some peripherals. The last time this
happened with the H6, which apart from re-organising the base addresses
also changed the clock controller significantly. We added a
CONFIG_SUN50I_GEN_H6 symbol back then to mark SoCs sharing those traits.
Now the Allwinner D1 changes the memory map again, and also extends the
pincontroller, among other peripherals.
To mark this generation of SoCs, add a CONFIG_SUNXI_GEN_NCAT2 symbol,
this name is reportedly used in the Allwinner BSP code, and prevents us
from inventing our own name.
Add this new symbol to some guards that were already checking for the H6
generation, since many features are shared between the two (like the
renovated clock controller).
This paves the way to introduce a first user of this generation.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Tested-by: Samuel Holland <samuel@sholland.org>
On the Allwinner platform we were describing a quite comprehensive
memory map in a per-SoC header unser arch/arm.
In the old days that was used by every driver, but nowadays it should
only be needed by SPL drivers (not using the DT). Many addresses in
there were never used, and some are not needed anymore.
To avoid a dependency on CPU specific headers in an arch specific
directory, move the definition of the pinctroller MMIO base address into
the sunxi_gpio.h header, because the SPL routines for GPIO should be the
only one needing this address.
This is a first step towards getting rid of cpu_sun[x]i.h completely,
and allows to remove the inclusion of that file from the sunxi_gpio.h
header.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
U-Boot's generic GPIO_EXTRA_HEADER is a convenience symbol to allow code
to more easily include platform specific GPIO headers. This should not
be needed in a DM world anymore, since the generic GPIO framework
handles that nicely.
For Allwinner boards we still need to deal with non-DM GPIO in the SPL,
but this should become the exception, not the rule.
Make this more obvious by removing the definition of GPIO_EXTRA_HEADER,
and just force every legacy user of platform specific GPIO to include
the new sunxi_gpio.h header explicitly. Everyone doing so should feel
ashamed and should find a way to avoid it from now on.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Tested-by: Samuel Holland <samuel@sholland.org>
So far every Allwinner SoC used the same basic pincontroller/GPIO
register frame, and just differed by the number of implemented banks and
pins, plus some special functionality from time to time. However the D1
and successors use a slightly different pinctrl register layout.
Use that opportunity to drop "struct sunxi_gpio", that described that
MMIO frame in a C struct. That approach is somewhat frowned upon in the
Linux world and rarely used there, though still popular with U-Boot.
Switching from a C struct to a "base address plus offset" approach allows
to switch between the two models more dynamically, without reverting to
preprocessor macros and #ifdef's.
Model the pinctrl MMIO register frame in the usual "base address +
offset" way, and replace a hard-to-parse CPP macro with a more readable
static function.
All the users get converted over. There are no functional changes at
this point, it just prepares the stages for the D1 and friends.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Samuel Holland <samuel@sholland.org>
Tested-by: Samuel Holland <samuel@sholland.org>
Move the existing sunxi-specific low level pinctrl routines from
arch/arm/mach-sunxi into the existing GPIO code under drivers/gpio, so
that the common code can be shared outside of arch/arm.
This also takes the opportunity to move some definitions from our
header file into the driver C file, as they are private to the driver
and are not needed elsewhere.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Samuel Holland <samuel@sholland.org>
Tested-by: Samuel Holland <samuel@sholland.org>
The CONFIG_MACPWR Kconfig symbol is used to point to a GPIO that enables
the power for the Ethernet "MAC" (mostly PHY, really).
In the DT this is described with the phy-supply property in the MAC DT
node, pointing to a (GPIO controlled) regulator. Since we need Ethernet
only in U-Boot proper, and use a DM driver there, we should use the DT
instead of hardcoding this.
Add code to the sun8i_emac and sunxi_emac drivers to check the DT for
that regulator and enable it, at probe time. Then drop the current code
from board.c, which was doing that job before.
This allows us to remove the MACPWR Kconfig definition and the respective
values from the defconfigs.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Sam Edwards <CFSworks@gmail.com>
The CONFIG_SATAPWR Kconfig symbol was used to point to a GPIO that
enables the power for a SATA harddisk.
In the DT this is described with the target-supply property in the AHCI
DT node, pointing to a (GPIO controlled) regulator. Since we need SATA
only in U-Boot proper, and use a DM driver for AHCI there, we should use
the DT instead of hardcoding this.
Add code to the sunxi AHCI driver to check the DT for that regulator and
enable it, at probe time. Then drop the current code from board.c, which
was doing that job before.
This allows us to remove the SATAPWR Kconfig definition and the
respective values from the defconfigs.
We also select the generic fixed regulator driver, which handles those
GPIO controlled regulators.
Please note that the OrangePi Plus is a bit special here, it's a H3
board without native SATA, but with a USB-to-SATA bridge. The DT models
the SATA power via a VBUS supply regulator, which we don't parse yet in
the USB PHY driver. Use the hardcoded CONFIG_USB3_VBUS_PIN for that
board meanwhile.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Sam Edwards <CFSworks@gmail.com>
Reviewed-by: Samuel Holland <samuel@sholland.org>
This copies in some devicetree files from the official Linux kernel tree,
v6.6-rc6. It covers a board with the Allwinner T113s SoC, which shares
many devices with its RISC-V sibling, the Allwinner D1(s). This is the
reason for the core .dtsi files landing in the arch/riscv directory.
We are only adjusting the include path to accommodate for the differences
in the U-Boot build system.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Sync the devicetree files from the official Linux kernel tree, v6.6-rc6.
This is covering Allwinner SoCs with 32-bit ARM cores, minus the T113s
board and related .dtsi files, which come separately.
Only small changes: Bluetooth got enabled on the C.H.I.P., and a clock
got renamed. More interesting is the addition of a board, for which
U-Boot enablement patches are pending.
As before, this omits the non-backwards compatible changes to the R_INTC
controller, to remain compatible with older kernels.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Sync the devicetree files from the official Linux kernel tree, v6.6-rc6.
This is covering Allwinner SoCs with 64-bit ARM cores.
Only small cosmetic changes (clock name fixed), but we add the DT for
the new OrangePi Zero 3 board, for which U-Boot enablement patches are
pending.
As before, this omits the non-backwards compatible changes to the R_INTC
controller, to remain compatible with older kernels.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Extend the existing driver to support the SCIF serial ports on the
Renesas RZ/G2L (R9A07G044) SoC. This also requires us to ensure that if
there is a reset signal defined in the device tree, it is de-asserted
before we try to talk to the SCIF module.
Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Tested-by: Marek Vasut <marek.vasut+renesas@mailbox.org> # R-Car H3 Salvator-XS
The i.MX8MP DHCOM SoM production rev.200 is populated with M24C32-D
EEPROMs which have Additional Write lockable page at separate I2C
address. Describe the page in DT to make it available.
Disable the additional page in rev.100 SoM DTO as those devices
contain EEPROM without an Additional Write lockable page.
Signed-off-by: Marek Vasut <marex@denx.de>
Import device tree changes from Linux v6.6-rc6 for Amlogic A1 board.
Signed-off-by: Igor Prusov <ivprusov@salutedevices.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20231017213211.121550-3-ivprusov@salutedevices.com
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Make sure we have an IMX header before calling spl_load_imx_container,
since if we don't it will fail with -ENOENT. This allows us to fall back to
legacy/raw images if they are also enabled.
This is a functional change, one which likely should have been in place
from the start, but a functional change nonetheless. Previously, all
non-IMX8 images (except FITs without FIT_FULL) would be optimized out if
the only image load method enabled supported IMX8 images. With this change,
support for other image types now has an effect.
There are seven boards with SPL_LOAD_IMX_CONTAINER enabled: three with
SPL_BOOTROM_SUPPORT:
imx93_11x11_evk_ld imx93_11x11_evk imx8ulp_evk
and four with SPL_MMC:
deneb imx8qxp_mek giedi imx8qm_mek
All of these boards also have SPL_RAW_IMAGE_SUPPORT and
SPL_LEGACY_IMAGE_FORMAT enabled as well. However, none have FIT support
enabled. Of the six load methods affected by this patch, only SPL_MMC and
SPL_BOOTROM_SUPPORT are enabled with SPL_LOAD_IMX_CONTAINER.
spl_romapi_load_image_seekable does not support legacy or raw images, so
there is no growth. However, mmc_load_image_raw_sector does support loading
legacy/raw images. Since these images could not have been booted before, I
have disabled support for legacy/raw images on these four boards. This
reduces bloat from around 800 bytes to around 200.
There are no in-tree boards with SPL_LOAD_IMX_CONTAINER and AHAB_BOOT both
enabled, so we do not need to worry about potentially falling back to
legacy images in a secure boot scenario.
Future work could include merging imx_container.h with imx8image.h, since
they appear to define mostly the same structures.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
These error messages are missing newlines. Add them.
Fixes: 6e81ca220e ("imx: parse-container: Use malloc for container processing")
Signed-off-by: Sean Anderson <seanga2@gmail.com>
