This platform enables CONFIG_BOARD_EARLY_INIT_F and then has a
do-nothing board_early_init_f function. Change to not enabling the
option and so not needing an empty function.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
This platform enables CONFIG_BOARD_EARLY_INIT_F and then has a
do-nothing board_early_init_f function. Change to not enabling the
option and so not needing an empty function.
Signed-off-by: Tom Rini <trini@konsulko.com>
This platform enables CONFIG_BOARD_EARLY_INIT_F and then has a
do-nothing board_early_init_f function. Change to not enabling the
option and so not needing an empty function.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
This platform enables CONFIG_BOARD_EARLY_INIT_F and then has a
do-nothing board_early_init_f function. Change to not enabling the
option and so not needing an empty function.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>
This platform enables CONFIG_BOARD_EARLY_INIT_F and then has a
do-nothing board_early_init_f function. Change to not enabling the
option and so not needing an empty function.
Signed-off-by: Tom Rini <trini@konsulko.com>
New SoM revision use series termination for eMMC signals while older do
not. To prevent signal overshot on older revisions, DSR must be set and
limited. The eMMC type is used to differentiate between revisions.
Keep a table with all types, that are known to require DSR.
Signed-off-by: Paul Gerber <Paul.Gerber@ew.tq-group.com>
Signed-off-by: Max Merchel <Max.Merchel@ew.tq-group.com>
Update functions to use the common baseboard header and
select TQ_COMMON_BB Kconfig option for MBa6 and WRU4.
While at it, remove empty implementations that are now covered by
board/tq/common.
Signed-off-by: Paul Gerber <Paul.Gerber@ew.tq-group.com>
Signed-off-by: Max Merchel <Max.Merchel@ew.tq-group.com>
TQMa6 and other SoMs from TQ-Systems GmbH need a baseboard. Therefore
functionality of U-Boot board callbacks may be distributed between SoM
and baseboard implementation.
To prevent code duplication and boilerplate implement a baseboard specific
API for TQ boards with weak defaults that can be filled out for baseboard
implementations as needed.
Signed-off-by: Markus Niebel <Markus.Niebel@ew.tq-group.com>
Signed-off-by: Max Merchel <Max.Merchel@ew.tq-group.com>
The SoM (TQMa6) can be used on various baseboards. No modifications to
the SoM files should be required to use the SoM on different baseboards.
Therefore, include the SoM headers in the baseboard.
Signed-off-by: Max Merchel <Max.Merchel@ew.tq-group.com>
As the PHYTEC phyCORE-i.MX91 [1] is just another variant of the existing
PHYTEC phyCORE-i.MX93 SoM but with i.MX91 SoC populated instead, add it
to the existing board-code "phycore_imx93", and rename that board to
"phycore_imx91_93" to reflect the dual SoCs support. While at it, also
rename and change common files accordingly. This way i.MX91 and i.MX93
SoC variants of the phyCORE SoM share most of the code and documentation
without duplication, while maintaining own device-tree and defconfigs
for each CPU variant.
Supported features:
- 1GB LPDDR4 RAM
- Debug UART
- EEPROM
- eMMC
- Ethernet
- SD-card
- USB
Product page SoM:
[1] https://www.phytec.eu/en/produkte/system-on-modules/phycore-imx-91-93/
Signed-off-by: Primoz Fiser <primoz.fiser@norik.com>
Commit 488445cefa ("doc: Move FIT into its own directory") moved the
documentation in doc/uImage.FIT to doc/usage/fit, subsequently all
documents and example sources have been converted to reStructuredText.
Fix (almost) all of the remaining occurrences of the old path and
filenames across the tree.
The exception is doc/uImage.FIT/command_syntax_extensions.txt which
apparently has been removed entirely, or at least I was unable to
locate where that document is now.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
The downstream Raspberry Pi uses two namings for the revD
SoC device trees, both bcm2712d0-rpi-5-b and bcm2712-d-rpi-5-b
but it seems upstream has settled on just the later, so lets
use that as it's the name that maps both upstream and downstream.
Fixes: c15a791972 ("board/raspberrypi: add bcm2712d0-rpi-5-b for Raspberry Pi 5")
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
Reviewed-by: Matthias Brugger <mbrugger@suse.com>
Move the existing 16GB single-rank configuration to HW_CFG 0x03 and use
the previous HW_CFG 0x01 value for the new 16GB dual-rank configuration.
There is no hardware using the former 16GB single-rank configuration,
so reuse the HW_CFG value for the new 16GB dual-rank configuration,
which will be used in production.
Signed-off-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com>
Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
The memory controller configuration doesn't depend only on the memory
size, so refactor the code to use the memory configuration read from
the HW_CFG pin instead of the memory size.
Additionally, make use of one header file for all the memory
configurations.
Signed-off-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com>
Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
bootcmd_ti_mmc had cpsw0_qsgmii_phyinit related scripts even though this
was only relevant for the j721e/j7200 SoCs. This patch instead factors
out those scripts into a generic 'board_init' which is called as part of
bootcmd_ti_mmc.
This allows boards to more easily add custom behaviour to the ti_mmc
bootflow instead of having to modify the ti_common.env file.
Signed-off-by: Anshul Dalal <anshuld@ti.com>
Currently, U-Boot fails with an FDT patching error if the LG Optimus 2X
device tree lacks a panel node. Since the panel is optional hardware,
patching should be optional as well. Fix this by allowing bootflow to
continue if the panel node is missing.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Quentin Schulz <quentin.schulz@cherry.de> says:
This migrates the last user of the legacy LED API, IMX233-OLinuXino and
net/bootp.c, to the modern LED framework.
I do have concern about being able to use BOOTP in SPL? In which case, I
should probably add an additional check on CONFIG_IS_ENABLED(LED) in
addition to IS_ENABLED(CONFIG_LED_BOOT)?
I haven't tested this as I do not own an IMX233-OLinuXino, so please
give this a try if you own this device.
Then, since there's no user left of this legacy API, it is entirely
removed.
Link: https://lore.kernel.org/r/20251120-legacy-led-removal-v1-0-369d44338358@cherry.de
No user of the legacy LED API anymore (except Sunxi with the PinePhone
but that is now a Sunxi-specific implementation), so let's remove
anything related.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
This migrates the last user of the legacy LED API, IMX233-OLinuXino, to
the modern LED framework.
The current implementation does the following:
- lit the LED when booting,
- turn off the LED the moment a BOOTP packet is received,
The first step is easily reproduced by using the
/options/u-boot/boot-led property to point at the LED. Unfortunately,
the boot-led is only lit by U-Boot proper at the very end of the boot
process, much later than currently. We can however force the LED on
whenever the GPIO LED driver is bound by marking the LED as
default-state = "on", and this happens slightly before board_init() is
called. We then do not need /options/u-boot/boot-led property for that
anymore.
However, the second step relies on /options/u-boot/boot-led and
CONFIG_LED_BOOT being set to reproduce the same behavior and requires us
to migrate net/bootp.c to the modern LED framework at the same time to
keep bisectability.
I couldn't figure out how to map CONFIG_LED_STATUS_BIT=778 to an actual
GPIO on the SoC but according to the schematics[1] only one LED is
present. I couldn't also map the SoC pin number to an actual GPIO from
the IMX23 manual, but there's already one GPIO LED specified in the
Device Tree so my guess is all of those are one and the same.
This was only build tested as I do not own this device.
[1] https://github.com/OLIMEX/OLINUXINO/blob/master/HARDWARE/iMX233-OLinuXino-Mini/1.%20Latest%20hardware%20revision/iMX233-OLINUXINO-MINI%20hardware%20revision%20E/iMX233-OLINUXINO-MINI_Rev_E.pdf
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
For once, replacing the legacy LED API with a more lean alternative,
just for sunxi's SPL. IIUC, this would be one step closer to dropping
this deprecated subsystem altogether.
Also adding two DRAM cleanups for the A133 SoC. There is a third patch
which requires some changes, will care about that later.
Gitlab CI passed, and I booted that briefly on an A133 board and some
board with a GPIO controlled power LED.
Bring U-Boot support for the BeagleV-Fire by adding a device tree and
supporting board files etc.
Signed-off-by: Jamie Gibbons <jamie.gibbons@microchip.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
To gain access to certain registers that are protected by GMID, the SPL
must release XSPI ownership to the current core.
Signed-off-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Alice Guo <alice.guo@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
The maximum length of the board name is not 11 characters
but 14: 11 bytes for the prefix + 3 bytes for the u8 + 1 NULL byte.
Hence, this commit increases the size of the name buffer variable
to 15. Also, this commit fixes the format specifier for the rev_id
variable.
Signed-off-by: Francois Berder <fberder@outlook.fr>
Change to use default board_phys_sdram_size implementation in soc.c,
which will call SM API to get DDR size.
If board has special implementation for DDR size, then board_phys_sdram_size
could be implemented in board file to override the default one in soc.c.
Signed-off-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Alice Guo <alice.guo@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
We are trying to get rid of the legacy LED API and PinePhone is one of
the last ones requiring it.
Unlike all other users of the legacy LED API, PinePhone is controlling
the GPIO LED in SPL. Unfortunately, Sunxi doesn't enable DM support in
SPL because of tight space constraints, so we cannot make use of the
modern LED framework as that is based on DM_GPIO.
Since PinePhone is the last user of this API, I'm moving the logic to
Sunxi SPL code and will let this community decide how to handle this hot
potato.
The logic is extremely simplified as only one GPIO LED is currently
controlled in SPL by PinePhone. No need for handling multiple LEDs or
inverted polarity, let's keep it simple.
This however allows us to use the modern LED framework once in U-Boot
proper since this logic won't collide with the new framework.
Since the only misc drivers that were compiled in SPL were guarded by
CONFIG_LED_STATUS and CONFIG_LED_STATUS_GPIO, we can also disable
CONFIG_SPL_DRIVERS_MISC (which does nothing anymore).
This also saves some space for PinePhone in SPL and proper.
Tested-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Simon Glass <simon.glass@canonical.com>
Add XOPIRV identifier for Orange Pi RV to dts selection callback in SPL,
and to fdtfile environment variable default value selection in payload.
Signed-off-by: E Shattow <e@freeshell.de>
Reviewed-by: Hal Feng <hal.feng@starfivetech.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Set $fdtfile to the VisionFive 2 Lite DTB if the board is matched.
Reviewed-by: E Shattow <e@freeshell.de>
Signed-off-by: Hal Feng <hal.feng@starfivetech.com>
Add eeprom data format v3 support. Add onboard_module field in
ATOM4 and add "mac onboard_module <?>" command to modify it.
The onboard module field marks the additional modules compared
with VisionFive 2 board. Now we define
bit7-1: reserved, bit0: WIFI/BT
Signed-off-by: Hal Feng <hal.feng@starfivetech.com>
pcb_revision is stored in the pcb_revision field of ATOM4. Correct it.
Move the function description to the header file.
Return 0 instead of 0xFF if read_eeprom() fails.
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Fixes: aea1bd95b6 ("eeprom: starfive: Enable ID EEPROM configuration")
Signed-off-by: Hal Feng <hal.feng@starfivetech.com>
Directly return the DDR size instead of the field of 'DxxxExxx'.
Move the function description to the header file.
Return 0 instead of 0xFF if read_eeprom() fails.
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Fixes: aea1bd95b6 ("eeprom: starfive: Enable ID EEPROM configuration")
Signed-off-by: Hal Feng <hal.feng@starfivetech.com>
Neha Malcom Francis <n-francis@ti.com> says:
Typically we do not enable these configs by default but would still like to
have the option to start building them in our default build flow for
testing. Also there is the added advantage of users being able to see what
is needed in case they choose to enable these features.
Link: https://lore.kernel.org/r/20260226122508.2269682-1-n-francis@ti.com
Sparsh Kumar <sparsh-kumar@ti.com> says:
This series updates the Resource Management (RM) configuration files
for AM62 family devices to align with the TIFS v11.02.09 firmware.
Background
----------
With the latest TIFS firmware (v11.02.09), an additional virtual
interrupt and event is reserved for MCU cores to DM usage on am62x,
am62ax, and am62px devices. This series brings the rm-cfg and
tifs-rm-cfg files in sync with these firmware changes across both
TI reference boards and vendor boards.
These changes are backward compatible with older TIFS firmware versions.
Additionally, the am62x platform was originally introduced without a
tifs-rm-cfg.yaml file, unlike other platforms in the AM62 family.
This series addresses that gap and enables tifs-rm-cfg in binman for
am625-sk and am62p-sk platforms.
Changes
-------
TI reference boards (patches 1-4):
- Update rm-cfg.yaml for am62x, am62ax, am62px
- Sync am62px tifs-rm-cfg.yaml with TIFS firmware template
- Add missing tifs-rm-cfg.yaml for am62x
- Enable tifs-rm-cfg in binman for am625-sk and am62p-sk
Vendor boards (patches 5-9):
- beagleplay (am62x-based)
- phytec phycore_am62x
- toradex verdin-am62
- phytec phycore_am62ax
- toradex verdin-am62p
with the required interrupt reservation. The tifs-rm-cfg.yaml files
cannot be updated without access to the corresponding SysConfig files,
as both rm-cfg.yaml and tifs-rm-cfg.yaml must remain in sync.
Link: https://lore.kernel.org/r/20260225132425.3096103-1-sparsh-kumar@ti.com
With the latest v11.02.09 TIFS firmware, an additional
virtual interrupt and event is reserved for MCU cores
to DM usage on am62px devices.
Update the rm-cfg to reflect this new reservation.
Signed-off-by: Sparsh Kumar <sparsh-kumar@ti.com>
With the latest v11.02.09 TIFS firmware, an additional
virtual interrupt and event is reserved for MCU cores
to DM usage on am62ax devices.
Update the rm-cfg to reflect this new reservation.
Signed-off-by: Sparsh Kumar <sparsh-kumar@ti.com>
With the latest v11.02.09 TIFS firmware, an additional
virtual interrupt and event is reserved for MCU cores
to DM usage on am62x devices.
Update the rm-cfg to reflect this new reservation.
Signed-off-by: Sparsh Kumar <sparsh-kumar@ti.com>
With the latest v11.02.09 TIFS firmware, an additional
virtual interrupt and event is reserved for MCU cores
to DM usage on am62x devices.
Update the rm-cfg to reflect this new reservation.
Signed-off-by: Sparsh Kumar <sparsh-kumar@ti.com>
