Remove video_setup from evm_init sequence since video memory is getting
called at an earlier place to make sure video memory is reserved at
the end of RAM.
Suggested-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Devarsh Thakkar <devarsht@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
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>
Add am62x_beagleplay_* defconfig customized for the configuration of
BeaglePlay and drop the config fragments.
This is in preparation for dropping the dependency on ti vendor folder
entirely.
Signed-off-by: Nishanth Menon <nm@ti.com>
Add explicit boot_targets to indicate the specific boot sequence to
follow.
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
When config is enabled, the esm dt probe makes sense. Simplify by
dropping board specific checks.
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Neha Malcom Francis <n-francis@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>
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>
Currently the K3 selection for TARGET boards does not depend on the SoC
for which it is based. This leds to the odd ability to select for instance
both SOC_K3_AM625 and TARGET_J721E_A72_EVM.
To fix this the target choice should depend on the matching SOC config.
Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
Now that we have time conversion defines from in time.h there is no need
for each driver to define their own version.
Signed-off-by: Igor Prusov <ivprusov@salutedevices.com>
Reviewed-by: Svyatoslav Ryhel <clamor95@gmail.com> # tegra
Reviewed-by: Eugen Hristev <eugen.hristev@collabora.com> #at91
Reviewed-by: Caleb Connolly <caleb.connolly@linaro.org> #qcom geni
Reviewed-by: Stefan Bosch <stefan_b@posteo.net> #nanopi2
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.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>
To quote Andre:
The first few patches are some easy refactorings and fixes, most of them
actually don't change the generated binaries at all. Then there is a
defconfig for a new board, for which we just gained the .dts file from
the last kernel DT sync.
On top there is support for a new PMIC (AXP313), and LPDDR4 support for
the Allwinner H616 SoC, both of which are needed to support new devices
that appeared lately, especially cheap TV boxes.
While those are technically new features, they don't affect existing
boards, for instance the LPDDR4 support code is guarded by a new DRAM
type Kconfig variable. So the risk for regressions is very slim.
Gitlab CI passed, and I booted that briefly on some boards, including an
H616 and an H618 one (with LPDDR4).
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>
When building this with clang, we get a warning about having excess
parenthesis here, or that we're incorrectly using "==" when we want "=".
Correct these by using the common size macro.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
[Andre: Use SZ_512M as per Simon's suggestion]
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
So far we have a convoluted #ifdef mesh that guards the early AXP PMIC
setup in board.c. That combination of &&, || and negations is very hard
to read, maintain and especially to extend.
Fortunately we have those same conditions already modelled in the
Kconfig file, so they are actually redundant. On top of that the real
reason we have those preprocessor guards in the first place is about the
symbols that are *conditionally* defined: without #ifdefs the build
would break because of them being undefined for many boards.
To simplify this, just change the guards to actually look at the symbols
needed, so CONFIG_AXP_xxx_VOLT instead of CONFIG_AXPyyy_POWER.
This drastically improves the readability of this code, and makes adding
PMIC support a pure Kconfig matter.
Doing this revealed one bug in Kconfig: there is no axp_set_dcdc4() for
the AXP818, even though CONFIG_AXP_DCDC4_VOLT includes that PMIC.
Since the AXP818 wasn't included when calling axp_set_dcdc4() in board.c,
this wasn't an issue, but becomes one now, so also remove the AXP818 from
the DCDC4 Kconfig symbol.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
The build instructions for the hikey960 had some broken links. Update
the links to use new vendor URLs. Also change build instructions to
reference a different file name.
Signed-off-by: Dylan Corrales <deathcamel58@gmail.com>
Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
- 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.
It's happened that glitches on the STM32_RST and STM32_BOOT lines have
put the STM32 companion microcontroller into DFU mode making it not boot
its FW, rendering it useless for the user.
Considering that the STM32 companion microcontroller is always reset on
a reboot or power cycle, resetting it once again in U-Boot SPL isn't
going to hurt it any more.
For ATtiny companion microcontroller, the situation is a bit different
because a reboot or power cycle doesn't reset it. Additionally, since it
can only be reset with a UPDI reset on the STM32_RST line, and that is
virtually impossible to mistakenly trigger, the ATtiny is unlikely to be
in unwanted reset or enter reset because U-Boot toggles STM32_RST line.
Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.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>
As we call sprintf in this file we need to include vsprintf.h in order
to get the function prototype and we need linux/string.h for strcmp.
Signed-off-by: Tom Rini <trini@konsulko.com>
As we call sprintf in this file we need to include vsprintf.h in order
to get the function prototype and we need linux/string.h for strcmp.
Signed-off-by: Tom Rini <trini@konsulko.com>
Given that this file references CFG_* defines, we need to be explicit in
our inclusion of config.h, so that these will be defined.
Reviewed-by: Aleksandar Gerasimovski <aleksandar.gerasimovski@hitacienergy.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
Rather than selecting CMD_QFW, we should make the option itself by
enabled by default on these platforms. Then in the board-specific
Kconfig we should select the appropriate back-end as needed if the
command is enabled.
Signed-off-by: Tom Rini <trini@konsulko.com>
This adds support for the Inteno XG6846 board based on the
Broadcom MIPS 6328 SoC.
The default boot will read a uImage from flash and boot it.
Reviewed-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Move ASUS Transformers, Grouper, P895 and P880 config fragments into
their respective device directory in /board/../configs/
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Remove nvidia_board_late_init calls from board since this setup is
performed in board2 of mach-tegra. Call of nvidia_board_late_init
from within the board does not provide any additional data.
Tested-by: Andreas Westman Dorcsak <hedmoo@yahoo.com> # ASUS Transformer T30
Tested-by: Svyatoslav Ryhel <clamor95@gmail.com> # LG P895 T30
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Default configuration matches values which are set in the board
so this configuration is not required.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
