u-boot.git/configs/turris_omnia_defconfig, branch next

sata: Rework the CMD_SATA and SATA symbols

2026-04-03T18:06:14+00:00

Today we typically enable CMD_SATA in order to have the SATA
functionality itself enabled, despite there being a clean split between
the two symbols. This in turn leads to potential configuration problems.
Split things so that SATA continues to be separate and not CMD_SATA
instead depends, functionally, on AHCI being enabled.

To do all of this:
- Have X86 select AHCI directly rather than "default y" it later.
- Make CMD_SATA be a default y option, given the split of platforms that
  enabled SATA and did, or did not, enable CMD_SATA.
- Change "imply CMD_SATA" to "imply SATA"
- Correct TARGET_VEXPRESS64_JUNO because you cannot select SATA_SIL
  without PCI (and in turn, SATA is needed for SATA_SIL).
- Update a number of defconfigs to have no functional change.

Signed-off-by: Tom Rini

env: Rename SYS_RELOC_GD_ENV_ADDR to ENV_RELOC_GD_ENV_ADDR

2025-06-20T18:15:08+00:00

Rename the variable and add ENV_ prefix, so that all configuration
options which are related to environment would have an CONFIG_ENV_
prefix. No functional change.

Reviewed-by: Tom Rini 
Signed-off-by: Marek Vasut

spl: Add an SPL_HAVE_INIT_STACK option

2025-03-13T16:36:09+00:00

At present there is a hex value SPL_STACK which both determines whether
SPL has its own initial stack and the hex value of that stack.

Split off the former into SPL_HAVE_INIT_STACK with SPL_STACK depending
on that and only providing the latter.

Signed-off-by: Simon Glass 
[trini: Resync defconfig files]

configs: Resync with savedefconfig

2024-11-12T21:00:36+00:00

Rsync all defconfig files using moveconfig.py

Signed-off-by: Tom Rini

Merge patch series "Implement ACPI on aarch64"

2024-10-28T00:44:13+00:00

Patrick Rudolph  says:

Based on the existing work done by Simon Glass this series adds
support for booting aarch64 devices using ACPI only.
As first target QEMU SBSA support is added, which relies on ACPI
only to boot an OS. As secondary target the Raspberry Pi4 was used,
which is broadly available and allows easy testing of the proposed
solution.

The series is split into ACPI cleanups and code movements, adding
Arm specific ACPI tables and finally SoC and mainboard related
changes to boot a Linux on the QEMU SBSA and RPi4. Currently only the
mandatory ACPI tables are supported, allowing to boot into Linux
without errors.

The QEMU SBSA support is feature complete and provides the same
functionality as the EDK2 implementation.

The changes were tested on real hardware as well on QEMU v9.0:

qemu-system-aarch64 -machine sbsa-ref -nographic -cpu cortex-a57 \
                    -pflash secure-world.rom \
                    -pflash unsecure-world.rom

qemu-system-aarch64 -machine raspi4b -kernel u-boot.bin -cpu cortex-a72 \
-smp 4 -m 2G -drive file=raspbian.img,format=raw,index=0 \
-dtb bcm2711-rpi-4-b.dtb -nographic

Tested against FWTS V24.03.00.

Known issues:
- The QEMU rpi4 support is currently limited as it doesn't emulate PCI,
  USB or ethernet devices!
- The SMP bringup doesn't work on RPi4, but works in QEMU (Possibly
  cache related).
- PCI on RPI4 isn't working on real hardware since the pcie_brcmstb
  Linux kernel module doesn't support ACPI yet.

Link: https://lore.kernel.org/r/20241023132116.970117-1-patrick.rudolph@9elements.com

drivers: ata: Rename ahci_mvebu

2024-10-27T23:24:13+00:00

Rename 'ahci_mvebu' to 'ahci_generic' and select it by default.
The AHCI driver contains no SoC specific code and only expects the
base address to be passed, thus rename it to ahci_generic and add the
DT compatible string "generic-ahci".

Update existing defconfigs to use the new Kconfig name as well.

TEST: Booted on QEMU sbsa using the generic-ahci node.

Signed-off-by: Patrick Rudolph 
Reviewed-by: Stefan Roese 
Cc: Tom Rini 
Cc: Stefan Roese 
Acked-by: Tony Dinh

configs: Resync with savedefconfig

2024-10-08T15:28:10+00:00

Rsync all defconfig files using moveconfig.py

Signed-off-by: Tom Rini

arm: mvebu: turris_omnia: Use the i2c_eeprom misc driver for EEPROM reading in U-Boot proper

2024-09-03T12:24:32+00:00

Use the i2c_eeprom miscellaneous driver for reading Turris Omnia EEPROM
in U-Boot proper. Keep using dm_i2c_read() in SPL build, since adding
the i2c_eeprom driver to SPL build increases the image by 1.5 KiB.

Signed-off-by: Marek Behún 
Reviewed-by: Stefan Roese

arm: mvebu: turris_omnia: Enable the 'eeprom' command

2024-07-08T06:20:58+00:00

Enable the 'eeprom' command with support for EEPROM layout for Turris
Omnia. Enable the i2c-eeprom driver so that the EEPROM is accessed via
driver model.

Signed-off-by: Marek Behún

arm: mvebu: turris_omnia: Fix ethernet PHY reset gpio FDT fixup

2024-07-08T06:20:58+00:00

For board revisions where the WAN ethernet PHY reset GPIO is controllable
via MCU we currently insert a phy-reset-gpios property into the ethernet
controller node. The mvneta driver parses this property and uses the
GPIO to reset the PHY.

But this phy-reset-gpios property is not a valid DT binding in upstream
kernel. Instead, a reset-gpios property should be inserted into the
ethernet PHY node. This correct DT binding is supported by the DM ETH PHY
U-Boot driver.

Insert the reset-gpios property into the WAN PHY node instead the
phy-reset-gpios property in WAN ETH node so that Linux will correctly use
the reset GPIO.

Enable the CONFIG_DM_ETH_PHY config option so that U-Boot will also use
the correct DT property.

Note: currently there are 4 ethernet controller drivers parsing the
wrong DT property: dwc_eth_qos, fex_mxc, mvneta and mvpp2. We should
convert all relevant device-trees to use reset-gpios so that we can get
rid of these drivers parsing this property.

Fixes: 1da53ae26afc ("arm: mvebu: turris_omnia: Add support for design with SW reset signals")
Signed-off-by: Marek Behún