Tom Rini [Fri, 5 Jul 2024 20:34:07 +0000 (14:34 -0600)]
Revert "buildman: Always use the full path in CROSS_COMPILE"
There are operations in buildman that result in running the cross-tools
(such as performing size checks) and now that we have not modified PATH
to know where our tools are, these operations fail.
Tom Rini [Mon, 8 Jul 2024 14:47:00 +0000 (08:47 -0600)]
Merge branch 'master' of https://gitlab.denx.de/u-boot/custodians/u-boot-marvell
- Add mvebu_espressobin_ultra-88f3720_defconfig (Benjamin)
- Update DTS for Thecus N2350 board (Tony)
- Add "old" Marvell DDR3 training for Armada 38x and Turris Omnia
(Marek)
- Misc turris_omnia changes (Marek)
- Fixes for i.MX8M and i.MX93 clk-composite.
- Set CAN oscillator frequency based on model on verdin-imx8mm.
- Enable CAAM for phycore-imx8mp_defconfig.
- Miscellaneous improvements for Gateworks i.MX8M boards.
- Fix initramfs boot on msc_sm2s_imx8mp.
- Fixe EQoS on imx8mp-beacon-kit.
- Fix error message in fsl_esdhc_imx.
Robert Marko [Fri, 21 Jun 2024 09:46:02 +0000 (11:46 +0200)]
mvebu: armada-8k: respect CONFIG_DISTRO_DEFAULTS
Currently, Armada 8k config header is setting boot devices and including
<config_distro_bootcmd.h> regardless of the CONFIG_DISTRO_DEFAULTS being
enabled or not, thus populating the environment for distro boot even on
devices that have no need for it.
So, lets simply respect the value of CONFIG_DISTRO_DEFAULTS.
Marek Behún [Tue, 18 Jun 2024 15:34:39 +0000 (17:34 +0200)]
arm: mvebu: turris_omnia: Support old DDR3 training
Support old DDR3 training code on Turris Omnia, selectable via EEPROM
field.
Users experiencing DDR3 initialization failures or random crashes of the
operating system due to incorrect DDR3 configuration can select the old
DDR3 training implementation to fix those issues by setting the EEPROM
field "Use old DDR training":
eeprom update "Use old DDR training" 1
Marek Behún [Tue, 18 Jun 2024 15:34:38 +0000 (17:34 +0200)]
arm: mvebu: a38x: Add optional support for using old DDR3 training code
Add optional support for using old DDR3 training code from 2017.
The code lives in drivers/ddr/marvell/a38x/old/. To prevent symbol
clashing with new DDR3 training code, a special header which renames all
clashing symbols via macros is included and the symbols are prefixed
with 'old_'.
If old DDR3 training support is selected for a board, then the SPL
initialization code calls a new function
board_use_old_ddr3_training()
to check whether it should use old DDR3 training code. The default
weak implementation returns false, defaulting to new DDR3 training code.
Boards that wish to support this need to select the
ARMADA_38X_SUPPORT_OLD_DDR3_TRAINING
config option and implement the old version of DDR topology provider,
ddr3_get_topology_map().
Marek Behún [Tue, 18 Jun 2024 15:34:35 +0000 (17:34 +0200)]
ddr: marvell: a38x: Import old DDR training code from 2017 version of U-Boot
Import DDR training code from commit 1b69ce2fc0ec ("arm: mvebu:
ddr3_debug: remove self assignments") into
drivers/ddr/marvell/a38x/old/. The code is not used yet.
Explanation:
Since 2019, on some Turris Omnia boards we have been having problems
with newer versions of Marvell's DDR3 training code for Armada 38x,
which is ported from mv-ddr-marvell [1] to U-Boot into the
drivers/ddr/marvell/a38x/ directory:
- sometimes the DDR3 training fails on some older boards, sometime it
fails on some newer boards
- other times it succeeds, but some boards experience crashes of the
operating system after running for some time.
Using the stock version of Turris Omnia's U-Boot from solved these
issues, but this solution was not satisfactory, since we wanted
features from new U-Boot.
Back in 2020-2022 we have spent several months trying to debug the
issues, working with Marvell, on our own, and also with U-Boot
community, but these issues persist still.
One solution we used back in 2019 was a "hybrid U-Boot": the SPL part
(containing the DDR3 training code) was taken from the stock version,
while the proper part was current U-Boot at the time. This solution also
has its drawbacks, of which the main one is the need to glue binaries
from two separate builds.
Since then there have been some more changes to the DDR3 training code
in upstream mv-ddr-marvell that have been ported to U-Boot. We have
provided our users experimental builds of U-Boot in the TurrisOS so that
they could try upgrading the firmware and let us know if those problems
still exist. And they do.
We do not have the time nor manpower to debug this problem and fix it
properly. Marvell was also no able to provide a solution to this,
probably because they do not have the manpower as well.
I have therefore come up with this "not that pretty" solution: take the
DDR3 training code from an older version of U-Boot that is known to
work, put it into current U-Boot under old/ subdirectory within
drivers/ddr/marvell/a38x/, build into the SPL binary both the old and
new versions and make it possible to select the old version via an env
variable.
Marek Behún [Tue, 18 Jun 2024 15:34:34 +0000 (17:34 +0200)]
arm: mvebu: turris_omnia: Read DDR speed from EEPROM
Some Turris Omnia boards experience memory issues, and by
experimentation we found that some of these issues can be solved by
slowing DDR speed.
Add a new field in the extended EEPROM information structure, ddr_speed.
Support several values in this field (for now 1066F, 1333H, and the
default, 1600K) and use it to overwrite the DDR topology parameters
used by the DDR training algorithm.
Marek Behún [Tue, 18 Jun 2024 15:34:32 +0000 (17:34 +0200)]
arm: mvebu: turris_omnia: Enable the 'eeprom' command
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.
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 <kabel@kernel.org>
Marek Behún [Tue, 18 Jun 2024 15:34:27 +0000 (17:34 +0200)]
ddr: marvell: a38x: debug: Define DDR_VIEWER_TOOL variables only if needed, and make them static
The variables is_validate_window_per_if, is_validate_window_per_pup,
sweep_cnt and is_run_leveling_sweep_tests are only used if
DDR_VIEWER_TOOL macro is defined, so define them only in that case.
Make them static since they are only used in ddr3_debug.c.
Marek Behún [Tue, 18 Jun 2024 15:34:25 +0000 (17:34 +0200)]
ddr: marvell: a38x: debug: return from ddr3_tip_print_log() early if we won't print anything
Return from ddr3_tip_print_log() early if we won't print anything
anyway.
This way the compiler can optimize away the VALIDATE_IF_ACTIVE() calls
in the for-loop, so if the SILENT_LIB macro is defined, no code is
generated for the rest of the function, which saves some space.
Tony Dinh [Mon, 10 Jun 2024 00:34:31 +0000 (17:34 -0700)]
arm: dts: mvebu: Update DTS for Thecus N2350 board
- Change the spi-max-frequency to 50000000 (50 Mhz). According to the
data sheet[1], the MX25L3205D max frequency is 86 Mhz. Using 50 Mhz in
the DTS to ensure u-boot is consistent with what Linux kernel expected.
- Update GPIO fan to conform to the latest DT binding.
Tony Dinh [Thu, 6 Jun 2024 00:12:01 +0000 (17:12 -0700)]
arm: mvebu: env_sf_get_env_addr() missing check for CONFIG_ENV_IS_IN_SPI_FLASH
The CONFIG_ENV_OFFSET is undefined if boot device is UART
(CONFIG_MVEBU_SPL_BOOT_DEVICE_UART), or envs are not stored on flash
(CONFIG_ENV_IS_NOWHERE). Check for CONFIG_ENV_IS_IN_SPI_FLASH as the first
condition to determine whether env_sf_get_env_addr() should be provided.
The CORE/BUS root slice has following design, simplied graph:
The difference is core not have pre_div block.
A composite core/bus clk has 8 inputs for mux to select, saying clk[0-7].
It support target(smart) interface and normal interface. Target interface
is exported for programmer easy to configure ccm root. Normal interface
is also exported, but we not use it in our driver, because it will
introduce more complexity compared with target interface.
The mux in the upper pic is not the target interface MUX, target
interface MUX is hiding SEL_A and SEL_B. When you choose clk[0-7],
you are actually writing SEL_A or SEL_B depends on the internal
counter which will also control the internal "mux".
The target interface simplified as below which is used by Linux Kernel:
CLK[0-7]--->MUX-->Gate-->pre_div-->post_div
A requirement of the Target Interface's software is that the
target clock source is active, it means when setting SEL_A, the
current input clk to SEL_A must be active, same to SEL_B.
We touch target interface, but hardware logic actually also need
configure normal interface.
There will be system hang, when doing the following steps:
The initial state:
SEL_A/SEL_B are both sourcing from clk0, the internal counter
choose SEL_A.
1. switch mux from clk0 to clk1
The hardware logic will choose SEL_B and configure SEL_B to clk1.
SEL_A no changed.
2. gate off clk0
Disable clk0, then the input to SEL_A is off.
3. switch from clk1 to clk2
The hardware logic will choose SEL_A and configure SEL_A to clk2,
however the current SEL_A input clk0 is off, the system hang.
The solution to fix the issue is in step 1, write twice to
target interface MUX, it will make SEL_A/SEL_B both sources
from clk1, then no need to care about the state of clk0. And
finally system performs well.
Signed-off-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
Adam Ford [Thu, 4 Jul 2024 21:22:46 +0000 (16:22 -0500)]
ARM: dts: imx8mp-beacon-kit-u-boot: Drop EQoS clock work-around
Since commit ecb1c37a7b64 ("clk: imx8mp: Add EQoS MAC clock"),
the clocks for the DWMAC driver can be configured, and removing
them breaks operation.
Fixes: ecb1c37a7b64 ("clk: imx8mp: Add EQoS MAC clock") Suggested-by: Tim Harvey <tharvey@gateworks.com> Signed-off-by: Adam Ford <aford173@gmail.com> Reviewed-by: Peng Fan <peng.fan@nxp.com>
Before this commit, usb_get_descriptor() failed for some flakey USB
devices. We hereby adopt the more robust linux implementation [1].
For instance, for the "Alcor Micro Corp. Flash Drive" (VID 0x058f, PID
0x6387), the following behavior occurs from time to time:
=> usb start
starting USB...
Bus xhci_pci: Register 10000840 NbrPorts 16
Starting the controller
USB XHCI 1.20
scanning bus xhci_pci for devices... usb_new_device: Cannot read configuration, skipping device 058f:6387
Signed-off-by: Philip Oberfichtner <pro@denx.de> Reviewed-by: Marek Vasut <marex@denx.de>
[1] From a38297e3fb012 (Linux 6.9), see
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/usb/core/message.c?h=v6.9#n781
Marek Vasut [Thu, 27 Jun 2024 00:13:16 +0000 (02:13 +0200)]
ARM: imx: Update Fast ethernet PHY MDIO addresses to match DH i.MX8MP DHCOM rev.200
The production DH i.MX8MP DHCOM SoM rev.200 uses updated PHY MDIO addresses
for the Fast ethernet PHYs. Update the base SoM DT and SoM rev.100 backward
compatibility DTO to cater for this change.
Since the MDIO address adjustment is now also in the rev.100 SoM DTO, not
only in the rev.100 PDK3 DTO, update Makefile accordingly as well, else the
DTC would complain about the DTO overriding the 'reg' property without also
updating the node unit-address, which is not doable without duplicating the
entire PHY node in the DTO, which leads to large amount of duplication with
no gain.
Fixes: 9de599ec3d59 ("arm64: dts: imx8mp: Update i.MX8MP DHCOM SoM DT to production rev.200") Signed-off-by: Marek Vasut <marex@denx.de>
Marek Vasut [Thu, 27 Jun 2024 00:13:15 +0000 (02:13 +0200)]
ARM: imx: Enable PCA953x driver on DH i.MX8MP DHCOM PDK2
Enable PCA953x GPIO expander driver in DH i.MX8MP DHCOM PDK2 configuration.
The PCA9539 GPIO expander is used on production DH i.MX8MP DHCOM SoM rev.200.
This is already enabled in DH i.MX8MP DHCOM PDK3 configuration so align the
two configurations.
Fixes: 9de599ec3d59 ("arm64: dts: imx8mp: Update i.MX8MP DHCOM SoM DT to production rev.200") Signed-off-by: Marek Vasut <marex@denx.de>
Marek Vasut [Tue, 25 Jun 2024 08:26:15 +0000 (10:26 +0200)]
ARM: imx: verdin-imx8mm: Set CAN oscillator frequency based on model
The older i.MX8M Mini Verdin SoMs may came with 20 MHz SPI CAN controller
oscillator, the newer SoMs always use 40 MHz oscillator. Handle both by
overriding the oscillator frequency just before booting the kernel.
These are the known variants with 20 MHz oscillator:
- 0055, V1.1A, V1.1B, V1.1C and V1.1D, use a 20MHz oscillator
- 0059, V1.1A and V1.1B, use a 20MHz oscillator
Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Tom Rini [Fri, 5 Jul 2024 22:36:43 +0000 (16:36 -0600)]
Merge branch '2024-07-05-assorted-updates'
- Re-instate the zlib update, so we can fix it for this release,
assorted whitespace cleanups, allow mkimage to 'auto-conf' signing of
scripts, enhance ELF image support, add more HW rev support to e1000
driver, update am64x_evm config, correct mpc8xxx watchdog, update
phycore-am6 docs.
Christophe Leroy [Thu, 27 Jun 2024 08:26:08 +0000 (10:26 +0200)]
watchdog: mpc8xxx: Fix timer value
Timer value is a 16 bits calculated from the wanted timeout and the
system clock. On powerpc/8xx, a timeout of 2s gives a value which
is over U16_MAX so U16_MAX shall be used. But the calculation is
casted to u16 so at the end the result is 63770 instead of 128906.
So the timer gets loaded with 63770 instead of 65535. It is not
a big difference in that case, but lets make the code correct and
cast to u32 instead of u16.
Fixes: 26e8ebcd7cb7 ("watchdog: mpc8xxx: Make it generic") Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Maxim Moskalets [Fri, 21 Jun 2024 11:42:10 +0000 (14:42 +0300)]
cmd: bootm: add ELF file support
Some operating systems (e.g. seL4) and embedded applications are ELF
images. It is convenient to use FIT-images to implement trusted boot.
Added "elf" image type for booting using bootm command.
Alexander Dahl [Thu, 20 Jun 2024 14:20:59 +0000 (16:20 +0200)]
mkimage: Allow 'auto-conf' signing of scripts
U-Boot configured for verified boot with the "required" option set to
"conf" also checks scripts put in FIT images for a valid signature, and
refuses to source and run such a script if the signature for the
configuration is bad or missing. Such a script could not be packaged
before, because mkimage failed like this:
% tools/mkimage -T script -C none -d tmp/my.scr -f auto-conf -k tmp -g dev -o sha256,rsa4096 my.uimg
Failed to find any images for configuration 'conf-1/signature'
tools/mkimage Can't add hashes to FIT blob: -1
Error: Bad parameters for FIT image type
This is especially unfortunate if LEGACY_IMAGE_FORMAT is disabled as
recommended.
Listing the script configuration in a "sign-images" subnode instead,
would have added even more complexity to the already complex auto fit
generation code.
Tom Rini [Fri, 5 Jul 2024 16:22:53 +0000 (10:22 -0600)]
Merge branch 'qcom-main' of https://source.denx.de/u-boot/custodians/u-boot-snapdragon
Various minor fixes and improvements:
* Fix Qualcomm SPMI v5 support
* Move default environment to a file
* Add support for special pins (e.g ufs/mmc reset/data pins)
* IPQ moves to OF_UPSTREAM and receives some cleanup and MAINTAINERS
changes
* Add a reset driver for devices without PSCI
* msm8916 USB clock improvements for mobile devices
Tom Rini [Fri, 5 Jul 2024 14:09:23 +0000 (08:09 -0600)]
Merge branch 'staging' of https://source.denx.de/u-boot/custodians/u-boot-tegra
Branch contains minor improvemets for existing tegra devices along
with bring up of 4 new devices (ASUS Transformers T20, Microsoft
Surface RT, Lenovo Ideapad Yoga 11 and WEXLER Tab 7t).
Caleb Connolly [Mon, 24 Jun 2024 02:23:29 +0000 (04:23 +0200)]
spmi: msm: correct max_channels for v5 controllers
Commit ee1d8aa5ecf7 ("spmi: msm: support controller version 7") broke
support for channels > 128 on v5 controllers, resulting in some
peripherals (like the power button / pon) working but others (like
gpios) reading bogus data.
Correct max_channels for v5 controllers.
Fixes: ee1d8aa5ecf7 ("spmi: msm: support controller version 7") Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
In order to help setup pin configuration for special pins (UFS, SDCard),
introduce the msm_special_pin_data struct largely inspired from the
Linux conterpart but with only U-Boot required fields.
This struct is added to the pins_data to allow specifying the special
pins data for each SoC.
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Sumit Garg <sumit.garg@linaro.org>
Sam Day [Mon, 6 May 2024 10:26:54 +0000 (10:26 +0000)]
clk/qcom: apq8016: add support for USB_HS clocks
The newer "register map for simple gate clocks" support added for qcom
clocks is used. As a result gcc_apq8016 now has a mixture of the old and
new styles. I didn't (and still don't!) feel comfortable enough in this
area to update the existing code.
Signed-off-by: Sam Day <me@samcday.com> Reviewed-by: Caleb Connolly <caleb.connolly@linaro.org> Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
Caleb Connolly [Tue, 7 May 2024 18:46:54 +0000 (18:46 +0000)]
qcom_defconfig: enable msm8916 and msm8996
Enable the clock/pinctrl drivers for these two SoCs. Previously left out
due to only being used on the db410c and db820c respectively which both
have their own board code. We can still boot these with most features
working without that board code.
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org> Signed-off-by: Sam Day <me@samcday.com>
Jonas Schwöbel [Sat, 2 Apr 2022 20:04:00 +0000 (22:04 +0200)]
board: lenovo: ideapad-yoga-11: add Lenovo Ideapad Yoga 11 support
The Lenovo IdeaPad Yoga 11 is a hybrid laptop/tablet Windows RT-based
computer released in late 2012. The device uses a 1.3 GHz quad-core
Nvidia Tegra 3 chipset with 2 GB of RAM, features a 11.6 inch 1366x768
screen and 32/64 GB of internal memory that can be supplemented with
a microSDXC card slot, full size SD card slot and 2 full size USB 2.0
ports.
Jonas Schwöbel [Mon, 24 Jan 2022 17:06:33 +0000 (18:06 +0100)]
board: microsoft: surface-rt: add Microsoft Surface RT support
Surface RT is a hybrid tablet computer developed and manufactured
by Microsoft and shipped with Windows RT. The tablet uses a 1.3 GHz
quad-core Nvidia Tegra 3 chipset with 2 GB of RAM, features 10.8
inch 1366x768 screen and 32/64 GB of internal memory that can be
supplemented with a microSDXC card giving up to 200 GB of
additional storage.
WEXLER Tab 7t is a mini tablet computer developed by WEXLER that
runs the Android operating system. The device features a 7.0-inch
(180 mm) HD display, an Nvidia Tegra 3 quad-core chip, 1 GB of RAM,
8, 16 or 32 GB of storage that can be supplemented with a microSDXC
card giving up to 64 GB of additional storage and a full size USB
port.
Tested-by: Maksim Kurnosenko <asusx2@mail.ru> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Svyatoslav Ryhel [Thu, 27 Jan 2022 17:42:04 +0000 (19:42 +0200)]
board: asus: transformer: add ASUS Transformer T20 family support
The Asus Eee Pad Transformer family are 2-in-1 detachable/slider
tablets developed by Asus that run the Android operating system.
The Eee Pad Transformers feature a 10.1-inch (260 mm) display,
an Nvidia Tegra 2 dual-core chip, 1 GB of RAM, and 16/32 GB of storage.
Transformers board derives from Nvidia Ventana development board.
This patch brings support for all 3 known T20 Transformers:
- Asus Eee Pad Transformer TF101
- Asus Eee Pad Transformer TF101G
- Asus Eee Pad Slider SL101
Tested-by: Robert Eckelmann <longnoserob@gmail.com> # ASUS TF101 Tested-by: Antoni Aloy Torrens <aaloytorrens@gmail.com> # ASUS TF101 Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Svyatoslav Ryhel [Tue, 18 Jun 2024 10:07:57 +0000 (13:07 +0300)]
include: configs: tegra-common-post: make usb first boot target
This ensures that the device can boot from a USB device prior to MMC. Useful
cases are when installing a new OS from USB while MMC still has a working OS
configuration or if the OS configuration is broken in late boot stages
(kernel boots but the system does not start).
Tom Rini [Thu, 4 Jul 2024 22:11:08 +0000 (16:11 -0600)]
Merge patch series "xtensa: Enable qemu-xtensa board"
Jiaxun Yang <jiaxun.yang@flygoat.com> says:
Hi all,
This series enabled qemu-xtensa board.
For dc232b CPU it needs to be built with toolchain[1].
This is a side product of me investigating architectures
physical address != virtual address in U-Boot. Now we can
get it covered under CI and regular tests.
VirtIO devices are not working as expected, due to U-Boot's
assumption on VA == PA everywhere, I'm going to get this fixed
later.
My Xtensa knowledge is pretty limited, Xtensa people please
feel free to point out if I got anything wrong.