Tim Harvey [Wed, 19 Jun 2024 21:13:39 +0000 (14:13 -0700)]
board: gateworks: venice: add print for GPY111 PHY name
Due to supply chain issues Venice boards use either a DP83867 or a
GPY111 RGMII PHY. We already print an identifier for the DP83867 so add
one for the GPY111 to better identify what PHY is on a board:
Tim Harvey [Wed, 19 Jun 2024 21:13:22 +0000 (14:13 -0700)]
board: gateworks: venice: delay before reading GSC EEPROM
Extensive testing has shown that at higher temperatures operating
without a GSC backup battery, the GSC needs a small delay after
releasing the I2C SDA/SCL pins before it is ready to handle I2C
requests.
Add a delay to avoid errors such as:
wait_for_sr_state: Arbitration lost sr=93 cr=80 state=2020
i2c_init_transfer: failed for chip 0x20 retry=0
Tim Harvey [Wed, 19 Jun 2024 21:12:58 +0000 (14:12 -0700)]
board: gateworks: venice: enable GSC supervisor for new board models
The Gateworks System Controller (GSC) has a voltage supervisor which is
disabled by default. On older boards we want to maintian this but on
newer boards we wish to enable the voltage supervisor.
The Gateworks System Controller (GSC) can disable the board primary
power supply by driving a pin to a FET high. On older board models
the leakage of the GSC may exceed the leakage of the FET causing this
signal slowly rise when the GSC battery is low and the board is in a
powered down state resulting in the board being kept in a disabled
state.
Newer boards have a hardware fix to avoid this leakage and thus should
enable the voltage supervisor.
hence these aren't dropped yet but there was an unused header:
- include/dt-bindings/pinctrl/pins-imx8mq.h
which has been dropped as well. There shouldn't be any funtional impact
with this change but it rather allows iMX platforms to use upstream
dt-bindings headers in a backwards compatible manner.
Signed-off-by: Sumit Garg <sumit.garg@linaro.org> Reviewed-by: Michael Trimarchi <michael@amarulasolutions.com>
Patrick Barsanti [Mon, 24 Jun 2024 12:13:11 +0000 (09:13 -0300)]
arm: fsl: imx8mn_bsh_smm_s2: Migrate to OF_UPSTREAM
Migrate imx8mn_bsh_smm_s2 and imx8mn_bsh_smm_s2pro boards to OF_UPSTREAM.
Signed-off-by: Patrick Barsanti <patrick.barsanti@amarulasolutions.com> Tested-by: Michael Trimarchi <michael@amarulasolutions.com> Reviewed-by: Peng Fan <peng.fan@nxp.com>
Tom Rini [Thu, 20 Jun 2024 14:46:06 +0000 (08:46 -0600)]
Merge patch series "boot: fix crash in bootflow menu with EFI BOOTMGR support + typos"
Quentin Schulz <foss+uboot@0leil.net> says:
bootflow menu currently crashes U-Boot with a NULL pointer dereference
because bootflow->dev is NULL for global bootmeths (such as EFI BOOTMGR).
Therefore, let's check if the bootflow is associated with a global
bootmeth before trying to make it part of the menu.
While this makes U-Boot not crash anymore, bootflow menu doesn't work
for me (I have never had a happy path with it, but I haven't actually
tried it before today :) ) and this was basically just implemented
following Simon's suggestion sent over IRC. No clue if this is enough or
just a quick band-aid patch.
Tom Rini [Thu, 20 Jun 2024 14:36:06 +0000 (08:36 -0600)]
Merge patch series "lib: smbios: Extend driver with using sysinfo driver"
Michal Simek <michal.simek@amd.com> says:
Hi,
currently only DT way is supported and it is added directly to lib/smbios.c
but I think DT and env is only one way how information can be found that's
why this series is improving handling with using sysinfo driver which can
be platform specific.
At the end of day DT should be taken from smbios.c and put to sysinfo DT
driver instead of implementing it directly in this generic file.
Quentin Schulz [Wed, 12 Jun 2024 14:58:49 +0000 (16:58 +0200)]
boot: bootflow_menu: fix crash for EFI BOOTMGR global bootmeth
The global bootmeths don't set the dev in bootflow struct which means
the dev_get_parent(bflow->dev) triggers a NULL-pointer dereference and
crash U-Boot.
So before trying to handle a bootflow, check that the associated
bootmeth isn't global, otherwise skip it.
Suggested-by: Simon Glass <sjg@chromium.org> Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> Reviewed-by: Simon Glass <sjg@chromium.org>
Michal Simek [Fri, 26 Apr 2024 13:38:13 +0000 (15:38 +0200)]
lib: smbios: Detect system properties via SYSINFO IDs
Code is pretty much supports only DT properties and completely ignore
information coming from sysinfo driver.
Code is calling smbios_add_prop() which calls with
smbios_add_prop_si(SYSINFO_ID_NONE). But SYSINFO_ID_NONE can't
differentiate different entries from sysinfo driver.
That's why introduce separate SYSINFO macros which can be used in sysinfo
driver and passed to smbios structure.
Signed-off-by: Michal Simek <michal.simek@amd.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Michal Simek [Fri, 26 Apr 2024 13:38:12 +0000 (15:38 +0200)]
lib: smbios: Let detect the system via sysinfo
Currently code looks like that it sysinfo drivers are supported but
actually none checking that system is detected. That's why call
sysinfo_detect() to make sure that priv->detected in sysinfo uclass is
setup hence information from driver can be passed to smbios.
Signed-off-by: Michal Simek <michal.simek@amd.com> Reviewed-by: Simon Glass <sjg@chromium.org>
board: ti: am64x: Set storage_interface and fw_dev_part ENVs
When ICSSG driver is enabled (CONFIG_TI_ICSSG_PRUETH=y) set
storage_interface and fw_dev_part env variables.
These variables need be set appropriately in order to load different
ICSSG firmwares needed for ICSSG driver. By default the storage
interface is mmc and the partition is 1:2. User can modify this based on
their needs.
Tom Rini [Wed, 19 Jun 2024 18:08:49 +0000 (12:08 -0600)]
Merge patch series "Add basic U-Boot Support for J722S-EVM"
Jayesh Choudhary <j-choudhary@ti.com> says:
Hello there,
This series add the U-Boot support for our new platform of K3-SOC
family - J722S-EVM which is a superset of AM62P. It shares the same
memory map and thus the nodes are being reused from AM62P includes
instead of duplicating the definitions.
Some highlights of J722S SoC (in addition to AM62P SoC features) are:
- Two Cortex-R5F for Functional Safety or general-purpose usage and
two C7x floating point vector DSP with Matrix Multiply Accelerator
for deep learning.
- Vision Processing Accelerator (VPAC) with image signal processor
and Depth and Motion Processing Accelerator (DMPAC).
- 7xUARTs, 3xSPI, 5xI2C, 2xUSB2, 2xCAN-FD, 3xMMC and SD, GPMC for
NAND/FPGA connection, OSPI memory controller, 5xMcASP for audio,
4xCSI-RX for Camera, 1 PCIe Gen3 controller, USB3.0 eCAP/eQEP,
ePWM, among other peripherals.
Tom Rini [Tue, 18 Jun 2024 16:47:10 +0000 (10:47 -0600)]
Merge patch series "EFI: ti: Enable EFI capsule updates"
Jonathan Humphreys <j-humphreys@ti.com> says:
Enable on disk capsule updates, which includes defining the firmware
components (tiboot3, spl, u-boot) and enabling processing of raw capsule
updates.
This is enabled for several TI SoC based platforms: AM64, AM62, AM62p,
AM69, BeaglePlay, J7, and BeagleboneAI. The configs to enable this are in a
single base config file. This will make it more scalable to add additional
EFI capsule features (like authentication) across all TI boards that have
capsules enabled.
This series also includes enabling serial flash DFU for AM62 and MMC DFU
for beagleplay.
board: sk-am69: Define capsule update firmware info
Define the firmware components updatable via EFI capsule update, including
defining capsule GUIDs for the various firmware components for the AM69
SK.
TODO: possibly make the struct's sk specific.
TODO: add doc commit (and make sure doc is sk/NOR specific, and add OSIP
boot mode)
TODO: update doc to show sk defconfig when building
Signed-off-by: Jonathan Humphreys <j-humphreys@ti.com> Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
board: beagleboneai64: Define capsule update firmware info
Define the firmware components updatable via EFI capsule update, including
defining capsule GUIDs for the various firmware components for the
BeagleBoneAI64.
Note this involved creating BeagleBoneAI64's own beagleboneai64.h board
header file instead of reusing j721e_evm's.
Signed-off-by: Jonathan Humphreys <j-humphreys@ti.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
board: am62px: Define capsule update firmware info
Define the firmware components updatable via EFI capsule update, including
defining capsule GUIDs for the various firmware components for the AM62px
SK.
Signed-off-by: Jonathan Humphreys <j-humphreys@ti.com> Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Define the firmware components updatable via EFI capsule update, including
defining capsule GUIDs for the various firmware components for the AM62x
SK.
Signed-off-by: Jonathan Humphreys <j-humphreys@ti.com> Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
board: beagleplay: Define capsule update firmware info
Define the firmware components updatable via EFI capsule update, including
defining capsule GUIDs for the various firmware components for the
BeaglePlay.
Note this involved creating BeaglePlay's own beagleplay.h board header file
instead of reusing am62_evm's.
Signed-off-by: Jonathan Humphreys <j-humphreys@ti.com> Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Define the firmware components updatable via EFI capsule update, including
defining capsule GUIDs for the various firmware components for the
SK-TDA4VM.
Signed-off-by: Jonathan Humphreys <j-humphreys@ti.com> Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Define the firmware components updatable via EFI capsule update, including
defining capsule GUIDs for the various firmware components for the AM64x
SK.
Signed-off-by: Jonathan Humphreys <j-humphreys@ti.com> Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Tom Rini <trini@konsulko.com>
configs: ti: Create base EFI capsule configs for TI K3 devices
To better scale with the number of boards, separate TI K3 EFI capsule
configs into its own file that can be shared across TI K3 boards. This
will allow any platform level config changes to be done once.
Signed-off-by: Jonathan Humphreys <j-humphreys@ti.com>
Created a capsule update porting section in the documentation that outlines
the steps a board developer must do when porting from an existing reference
board implementation.
In particular, added a big warning that new capsule GUID's need to be
defined.
Quentin Schulz [Mon, 10 Jun 2024 16:13:46 +0000 (18:13 +0200)]
smbios: only look for a SYSINFO udevice if SYSINFO support is enabled
If SYSINFO support isn't enabled, it's a given that uclass_first_device
for UCLASS_SYSINFO will not find anything, therefore let's skip the test
entirely.
This allows to get rid of the following debug message that may be
confusing:
Cannot find uclass for id 118: please add the UCLASS_DRIVER() declaration for this UCLASS_... id
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> Reviewed-by: Simon Glass <sjg@chromium.org>
Tom Rini [Tue, 18 Jun 2024 16:29:35 +0000 (10:29 -0600)]
Merge patch series "*** Various fixes & improvements for phycore-AM6* SoMs ***"
Wadim Egorov <w.egorov@phytec.de> says:
It includes various fixes and improvements for phyCORE-AM62x and
phyCORE-AM64x SoMs. Notable is the last patch which prepares for use
with future ECC memory fixups.
Wadim Egorov [Mon, 10 Jun 2024 13:33:52 +0000 (15:33 +0200)]
board: phytec: phycore-am62x: Use memory nodes in higher boot stages
There is no need to reread the EEPROM multiple times in different stages
to detect the RAM size. We can do this once at an early stage and let
higher stages decode memory nodes using fdtdec.
Make sure to pass fixup memory nodes before passing to u-boot stage.
Signed-off-by: Wadim Egorov <w.egorov@phytec.de> Reviewed-by: Daniel Schultz <d.schultz@phytec.de>
Tom Rini [Tue, 18 Jun 2024 14:35:30 +0000 (08:35 -0600)]
Merge tag 'u-boot-stm32-20240618' of https://source.denx.de/u-boot/custodians/u-boot-stm into next
STM32MP15/13
------------
_ Reserve OPTEE area in EFI memory map
_ net: dwc_eth_qos: add support for phy-reset-gpios property
_ Add eth1/2 support for stm32mp13
_ Add PWR regulator support for stm32mp13
_ Add pinmux nodes for DH electronics STM32MP13xx DHCOR SoM and DHSBC board
_ Add support for STM32MP13xx DHCOR SoM and DHSBC board
_ Set PLL4_P to 125Mhz for ETH_CLK for stm32mp157c-odyssey
_ Use internal clock for Tx for stm32mp157c-odyssey
_ Fix incorrect PHY address for stm32mp157c-odyssey
_ Add phy-reset-gpios property to ethernet node for stm32mp157c-odyssey
_ Add generic SoM compatible to STM32MP15xx DH electronics DHSOM
_ Auto-detect second MAC on STM32MP15xx DH electronics DHCOM
Marek Vasut [Thu, 6 Jun 2024 13:01:48 +0000 (15:01 +0200)]
ARM: dts: stm32: Auto-detect second MAC on STM32MP15xx DH electronics DHCOM
Test whether this system is compatible with STM32MP15xx DHCOM SoM,
if so, test whether R292 pull up is populated on pin PC3, which is
an indication that the second MAC chip, KS8851-16MLL, is populated.
Use this information to patch 'status' DT property into the second
ethernet MAC DT node and enable/disable the MAC on systems where
the chip is/isn't populated respectively.
Use spl_perform_fixups() to patch the U-Boot proper DT from SPL and
ft_board_setup() to patch Linux DT from U-Boot proper. This way both
software components are configured the same way.
Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Marek Vasut [Thu, 16 May 2024 23:47:04 +0000 (01:47 +0200)]
ARM: dts: stm32: Add generic SoM compatible to STM32MP15xx DH electronics DHSOM
Add generic SoM compatible string into machine compatible string
for all STM32MP15xx based DH electronics DHSOM. This way, common
board code can match on this compatible. No functional change.
Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
ARM: dts: stm32: use internal clock for Tx for stm32mp157c-odyssey
In Odyssey board, we should use the internal clock from RCC as the
transmit clock, instead of the external clock from ETH_CLK125 pad. This
commit adds a property, st,eth-clk-sel, so that the ETH_CLK_SEL mux
selects ETH_CLK.
Marek Vasut [Tue, 19 Mar 2024 02:45:08 +0000 (03:45 +0100)]
ARM: dts: stm32: Make PWR regulator driver available on STM32MP13xx
This patch makes STM32 PWR regulators available on stm32mp13xx.
This requires TFA to clear RCC_SECCFGR, is disabled by default
on stm32mp13xx and can only be enabled on board config level.
Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Marek Vasut [Tue, 19 Mar 2024 02:45:07 +0000 (03:45 +0100)]
ARM: dts: stm32: add PWR regulators support on stm32mp131
This patch adds STM32 PWR regulators DT support on stm32mp131.
This requires TFA to clear RCC_SECCFGR, is disabled by default
and can only be enabled on board DT level.
Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Since commit 7b78d6438a2b3 ("efi_loader: Reserve unaccessible memory")
memory region above ram_top is tagged in EFI memory map as
EFI_BOOT_SERVICES_DATA.
In case of STM32MP1/STM32MP13 platforms, above ram_top, there is one
reserved-memory region tagged "no-map" dedicated to OP-TEE :
_ addr=de000000 size=2000000 for stm32mp157x-dkx and stm32mp135f-dk
_ addr=fe000000 size=2000000 for stm32mp157c-ev1
Before booting kernel, EFI memory map is first built, the OPTEE region is
tagged as EFI_BOOT_SERVICES_DATA and when reserving LMB, the tag LMB_NONE
is used.
Then after, the LMB are completed by boot_fdt_add_mem_rsv_regions()
which try to add again the same OPTEE region (addr=de000000 size=2000000
in case of stm32mp157x-dkx / stm32mp135f-dk or addr=fe000000 size=2000000
in case for stm2mp157c-ev1)
but now with LMB_NOMAP tag which produces the following error message :
_ for stm32mp157x-dkx / stm32mp135f-dk :
"ERROR: reserving fdt memory region failed (addr=de000000 size=2000000 flags=4)"
_ for stm32mp157c-ev1 :
"ERROR: reserving fdt memory region failed (addr=fe000000 size=2000000 flags=4)"
To avoid this, OPTEE area shouldn't be used by EFI, so we need to mark
it as reserved.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Tom Rini [Mon, 17 Jun 2024 17:01:35 +0000 (11:01 -0600)]
Merge tag 'xilinx-for-v2024.10-rc1' of https://source.denx.de/u-boot/custodians/u-boot-microblaze into next
AMD/Xilinx changes for v2024.10-rc1
common:
- spl: Introduce SoC specific init function
xilinx:
- Enable FF-A and NVMEM
- Rename spl_board_init() to spl_soc_init()
zynqmp:
- DT alignments
- Enable reset from SPL
- Enable USB3 for KD240
- Align multiboot register on Kria for proper reboot
- Allow multiboot environment write even in saved environment
- Move zynqmp commands from board/ to arch/
- Clean up xilinx_zynqmp.h
versal:
- Do not prioritize boot device if driver is not enabled
versal-net:
- Setup location for redundant variables in SPI
versal2:
- Add support for new SOC
mmc:
- Fix tap delay for SD on Versal NET
spi:
- Add SPI_NOR_OCTAL_READ flag for mx66uw2g345gx0 flash part
ENV_OFFSET_REDUND config is by default set to 0 for flashes.
Saving the env variables is overwriting data at 0 offset,
which is wrong. So add default redund env offset
ENV_OFFSET_REDUND at 0x7F00000 for Versal NET platform.
Neal Frager [Tue, 4 Jun 2024 08:38:54 +0000 (09:38 +0100)]
arm64: zynqmp: Enable usb3 for k24 som
This patch corrects the mio and pll configuration registers for using usb3
on the kd240 starter kit. Without this patch, the usb3 to sd card bridge does
not initialize correctly and u-boot is unable to find the OS located on the
kd240 starter kit sd card.
In addition, this patch correctly configures mio76 and mio77 as gpio pins
which are used as reset gpio pins on the kd240 starter kit.
Michal Simek [Mon, 3 Jun 2024 13:09:01 +0000 (15:09 +0200)]
arm64: zynqmp: Setup multiboot register to 0
On Kria when board starts from Image A or Image B partition multiboot
register is already setup to that location. When reset command is called
board is issuing soft reset which start SW at already used location (offset
of multiboot * 32k).
But board should continue to run from multiboot offset 0 (start of QSPI)
and call early bootloader every reboot that's why clear multiboot register
to 0 by default to go that route all the time.
projects / u-boot.git / log