Fedor Ross [Mon, 16 Oct 2023 16:16:15 +0000 (18:16 +0200)]
ARM: imx: Add support for detecting primary/secondary bmode on MX8M
Implement the 'getprisec' subcommand of 'bmode' command for i.MX8M by
reading out the ROM log events. This event is set by the BootROM if it
switched to the secondary copy due to primary copy being corrupted.
Signed-off-by: Fedor Ross <fedor.ross@ifm.com> Signed-off-by: Marek Vasut <marex@denx.de>
Fedor Ross [Mon, 16 Oct 2023 16:16:14 +0000 (18:16 +0200)]
ARM: imx: Use correct U-Boot offset in case of secondary boot from eMMC
In case of a secondary image boot from the user area of an eMMC device,
the correct offset must be calculated. The offset is fused in the fuse
IMG_CNTN_SET1_OFFSET of the i.MX8M Nano and Plus. The calculation of the
offset is described in the reference manual (IMX8MNRM Rev. 2, 07/2022
and IMX8MPRM Rev. 1, 06/2021):
The fuse IMG_CNTN_SET1_OFFSET (0x490[22:19]) is defined as follows:
* Secondary boot is disabled if fuse value is bigger than 10,
n = fuse value bigger than 10.
* n == 0: Offset = 4MB
* n == 2: Offset = 1MB
* Others & n <= 10 : Offset = 1MB*2^n
Signed-off-by: Fedor Ross <fedor.ross@ifm.com> Signed-off-by: Marek Vasut <marex@denx.de>
Fedor Ross [Mon, 16 Oct 2023 16:16:13 +0000 (18:16 +0200)]
ARM: imx: Factor out parsing of ROM log
Factor out parsing of ROM log in function spl_mmc_emmc_boot_partition().
This can be helpful to detect a secondary image boot without fiddling
around with MMC partitions. This way for example, U-Boot is able to
detect a secondary image boot and can enter some fallback scenario like
starting a recovery mode.
Signed-off-by: Fedor Ross <fedor.ross@ifm.com> Signed-off-by: Marek Vasut <marex@denx.de>
Marek Vasut [Mon, 16 Oct 2023 16:16:12 +0000 (18:16 +0200)]
spl: mmc: Introduce proper layering for spl_mmc_get_uboot_raw_sector()
Introduce two new weak functions, arch_spl_mmc_get_uboot_raw_sector() and
board_spl_mmc_get_uboot_raw_sector(), each of which can be overridden at
a matching level, that is arch/ and board/ , in addition to the existing
weak function spl_mmc_get_uboot_raw_sector().
This way, architecture code can define a default architecture specific
implementation of arch_spl_mmc_get_uboot_raw_sector(), while the board
code can override that using board_spl_mmc_get_uboot_raw_sector() which
takes precedence over the architecture code. In some sort of unlikely
special case where code has to take precedence over board code too, the
spl_mmc_get_uboot_raw_sector() is still left out to be a weak function,
but it should be unlikely that this is ever needed to be overridden.
U-Boot SPL 2023.10-00558-g65b9b3462bec-dirty (Oct 03 2023 - 17:40:10 +0200)
SOC: 0xa0009300
LC: 0x40010
M33 prepare ok
Normal Boot
Trying to boot from BOOTROM
Boot Stage: Primary boot
image offset 0x8000, pagesize 0x200, ivt offset 0x0
Load image from 0x44400 by ROM_API
NOTICE: BL31: v2.8(release):android-13.0.0_2.0.0-0-ge4b2dbfa52f5
NOTICE: BL31: Built : 17:52:46, Sep 28 2023
That's because commit 9e644284ab81 ("dm: core: Report
bootph-pre-ram/sram node as pre-reloc after relocation"):
"[This] changes behavior of what nodes are bound in the U-Boot
proper pre-relocation phase. Change to bootph-all or add
bootph-some-ram prop to restore prior behavior."
Fix this by adding bootph-some-ram prop as suggested by the commit
above.
Fixes: 9e644284ab81 ("dm: core: Report bootph-pre-ram/sram node as pre-reloc after relocation") Signed-off-by: Sébastien Szymanski <sebastien.szymanski@armadeus.com> Reviewed-by: Fabio Estevam <festevam@gmail.com>
Paul Barker [Mon, 16 Oct 2023 09:25:43 +0000 (10:25 +0100)]
board: rzg2l: Add RZ/G2L SMARC EVK board
The Renesas RZ/G2L SMARC Evaluation Board Kit consists of the RZ/G2L
System-on-Module (SOM) based on the R9A07G044L2 SoC, and a common SMARC
carrier board.
The ARM TrustedFirmware code for the Renesas RZ/G2L SoC family passes a
devicetree blob to the bootloader as an argument in the same was
previous R-Car gen3/gen4 SoCs. This blob contains a compatible string
which can be used to identify the particular SoC we are running on and
this is used to select the appropriate device tree to load.
The configuration renesas_rzg2l_smarc_defconfig is added to support
building for this target. In the future this defconfig will be extended
to support other SoCs and evaluation boards from the RZ/G2L family.
Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Paul Barker [Mon, 16 Oct 2023 09:25:42 +0000 (10:25 +0100)]
arm: dts: Import RZ/G2L SMARC EVK device tree
The Renesas RZ/G2L SMARC Evaluation Board Kit consists of the RZ/G2L
System-on-Module (SOM) based on the R9A07G044L2 SoC, and a common SMARC
carrier board.
Paul Barker [Mon, 16 Oct 2023 09:25:41 +0000 (10:25 +0100)]
arm: rmobile: Support RZ/G2L memory map
The memory map for the RZ/G2L family differs from that of previous R-Car
Gen3/Gen4 SoCs.
A high level memory map can be seen in figure 5.2 (section 5.2.1) of the
RZ/G2L data sheet rev 1.30 published May 12, 2023. A summary is included
here (note that this is a 34-bit address space):
* 0x0_0000_0000 - 0x0_0002_FFFF SRAM area
* 0x0_0003_0000 - 0x0_0FFF_FFFF Reserved area
* 0x0_1000_0000 - 0x0_1FFF_FFFF I/O register area
* 0x0_2000_0000 - 0x0_2FFF_FFFF SPI Multi area
* 0x0_3000_0000 - 0x0_3FFF_FFFF Reserved area
* 0x0_4000_0000 - 0x1_3FFF_FFFF DDR area (4 GiB)
* 0x1_4000_0000 - 0x3_FFFF_FFFF Reserved area
Within the DDR area, the first 128 MiB are reserved by TrustedFirmware.
The region from 0x43F00000 to 0x47DFFFFF inclusive is protected for use
in TrustedFirmware/OP-TEE, but all other memory is included in the
memory map. This reservation is the same as used in R-Car
Gen3/Gen4 and RZ/G2{H,M,N,E} SoCs.
DRAM information is initialised based on the data in the fdt.
Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Paul Barker [Mon, 16 Oct 2023 09:25:40 +0000 (10:25 +0100)]
arm: rmobile: Add CPU detection for RZ/G2L
The ARM TrustedFirmware code for the Renesas RZ/G2L SoC family passes a
devicetree blob to the bootloader as an argument in the same was
previous R-Car Gen3/Gen4 SoCs. This blob contains a compatible string
which can be used to identify the particular SoC we are running on.
We do this as reading the DEVID & PRR registers from u-boot is not
sufficient to differentiate between the R9A07G044L (RZ/G2L) and
R9A07G044C (RZ/G2LC) SoCs. An additional read from offset 0x11861178 is
needed but this address is in the OTP region which can only be read from
the secure world (i.e. TrustedFirmware). So we have to rely on
TrustedFirmware to determine the SoC and pass this information to u-boot
via an fdt blob.
Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Paul Barker [Mon, 16 Oct 2023 09:25:38 +0000 (10:25 +0100)]
mmc: renesas-sdhi: Initialize module on RZ/G2L
On the Renesas RZ/G2L SoC family, we must ensure that the required clock
signals are enabled and the reset signal is de-asserted before we try to
communicate with the SDHI module.
Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Paul Barker [Mon, 16 Oct 2023 09:25:37 +0000 (10:25 +0100)]
mmc: renesas-sdhi: Refactor probe function
Move the assignment of priv->quirks earlier in the function. This allows
us to drop the quirks local variable and makes it easier to maintain
clean error handling when we add RZ/G2L support in the next patch.
Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com> Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Marek Vasut [Sun, 15 Oct 2023 22:41:14 +0000 (00:41 +0200)]
arm64: dts: imx8mp: Make GPIO3 available early in U-Boot proper on i.MX8MP DHCOM
The GPIO3 has to be available early during U-Boot proper start up for
DRAM size detect to work correctly. The GPIO3 is currently available in
SPL and late in U-Boot proper, which is insufficient. Add the missing
bootph-all to make the GPIO3 available also early in U-Boot proper.
The current imx8mp-dhcom-som.dtsi describes production rev.200 SoM,
add DT overlay which reinstates rev.100 SoM description to permit
prototype rev.100 SoMs to be used until they get phased out.
Marek Vasut [Thu, 21 Sep 2023 18:44:19 +0000 (20:44 +0200)]
arm64: dts: imx8mp: Drop i.MX8MP DHCOM rev.100 PHY address workaround from PDK3 DT
In case the i.MX8MP DHCOM rev.100 has been populated on the PDK3
carrier board, the on-SoM PHY PHYAD1 signal has been pulled high
by the carrier board and changed the PHY MDIO address from 5 to 7.
This has been fixed on production rev.200 SoM by additional buffer
on the SoM PHYAD/LED signals, remove the workaround.
Marek Vasut [Thu, 21 Sep 2023 18:44:18 +0000 (20:44 +0200)]
arm64: dts: imx8mp: Update i.MX8MP DHCOM SoM DT to production rev.200
The current imx8mp-dhcom-som.dtsi describes prototype rev.100 SoM,
update the DT to describe production rev.200 SoM which brings the
following changes:
- Fast SoC GPIOs exposed on the SoM edge connector
- Slow GPIOs like component resets moved to I2C GPIO expander
- ADC upgraded from TLA2024 to ADS1015 with conversion interrupt
- EEPROM size increased from 256 B to 4 kiB
Marek Vasut [Thu, 21 Sep 2023 18:44:17 +0000 (20:44 +0200)]
arm64: dts: imx8mp: Switch to DT overlays for i.MX8MP DHCOM SoM
Add DT overlays to support additional DH i.MX8MP DHCOM SoM 660-100
population options with 1x or 2x RMII PHY mounted on PDK2 or PDK3
carrier boards.
Use SPL DTO support to apply matching SoM specific DTO to cater
for the SoM differences. Remove ad-hoc patching of control DT from
fdtdec_board_setup().
Marek Vasut [Thu, 21 Sep 2023 18:44:16 +0000 (20:44 +0200)]
spl: fit: Add board level function to decide application of DTO
Add board-specific function used to indicate whether a DTO from fitImage
configuration node 'fdt' property DT and DTO list should be applied onto
the base DT or not applied.
This is useful in case of DTOs which implement e.g. different board revision
details, where such DTO should be applied on one board revision, and should
not be applied on another board revision.
Marek Vasut [Thu, 31 Aug 2023 14:57:24 +0000 (16:57 +0200)]
imx: hab: Use size parameter
The current code works by sheer coincidence, because (see HABv4 API
documentation, section 3.4) the RVT authenticate_image call updates
the size that is passed in with the actual size ROM code pulls from
IVT/CSF . So if the input size is larger, that is "fine" . Pass in
size instead to make this really correct.
Tom Rini [Sat, 7 Oct 2023 19:36:58 +0000 (15:36 -0400)]
cmd/ti: Update Kconfig logic and Makefile recursion logic
- Add some dependencies to CMD_DDR3 as this is only valid on some
platforms (which tend to select it as well).
- The proper gate for going in to cmd/ti is not
CONFIG_TI_COMMON_CMD_OPTIONS as nothing under there is controlled by
that symbol but the general TI architecture options.
Tom Rini [Sat, 7 Oct 2023 19:13:08 +0000 (15:13 -0400)]
cmd: Convert existing long help messages to the new macro
- Generally we just drop the #ifdef CONFIG_SYS_LONGHELP and endif lines
and use U_BOOT_LONGHELP to declare the same variable name as before
- In a few places, either rename the variable to follow convention or
introduce the variable as it was being done inline before.
Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Tom Rini [Sat, 7 Oct 2023 19:13:07 +0000 (15:13 -0400)]
command.h: Add a U_BOOT_LONGHELP macro
In order to be able to discard unused long help texts without further
linker lists, add a macro for defining the long help messages which uses
__maybe_unused. This allows us to discard them as unreferenced as part
of the link.
Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Paul Barker [Mon, 16 Oct 2023 09:25:33 +0000 (10:25 +0100)]
gpio: Add RZ/G2L GPIO driver
This driver adds support for the gpio features of the GPIO/PFC module in
the Renesas RZ/G2L (R9A07G044) SoC.
The new `rzg2l-pfc-gpio` driver is bound to the same device tree node as
the `rzg2l-pfc-pinctrl` driver as the same hardware block provides both
GPIO and pin multiplexing features.
Paul Barker [Mon, 16 Oct 2023 09:25:32 +0000 (10:25 +0100)]
pinctrl: renesas: Add RZ/G2L PFC driver
This driver adds support for the pinctrl features of the GPIO/PFC module
in the Renesas RZ/G2L (R9A07G044) SoC.
A multi-function `rzg2l-pfc` driver is defined for UCLASS_NOP, which
binds the `rzg2l-pfc-pinctrl` UCLASS_PINCTRL driver dynamically. We also
define common macros and functions for the PFC in <renesas/rzg2l-pfc.h>.
This makes it easy to add an additional UCLASS_GPIO driver for the GPIO
functionality of this module in a follow-up patch.
Paul Barker [Mon, 16 Oct 2023 09:25:31 +0000 (10:25 +0100)]
cmd: gpio: Skip output on -ENOENT
On the Renesas RZ/G2L SoC family, valid GPIO numbers are not contiguous.
This is determined by the device tree, where a fixed number of bits are
used for the 'pin' number within a 'port', even though not all ports
have the same number of pins. The device tree can't be changed here
without breaking backwards compatibility in Linux, which we don't want
to do.
To avoid printing a status for each of these invalid GPIO numbers when
a user executes `gpio status -a`, we allow gpio_get_function() to return
-ENOENT when the given offset does not refer to a valid GPIO pin and we
skip printing anything if this occurs.
Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com> Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Paul Barker [Mon, 16 Oct 2023 09:25:29 +0000 (10:25 +0100)]
clk: renesas: Add RZ/G2L & RZ/G2LC CPG driver
This driver provides clock and reset control for the Renesas R9A07G044L
(RZ/G2L) and R9A07G044C (RZ/G2LC) SoC. It consists of two parts:
* driver code which is applicable to all SoCs in the RZ/G2L family.
* static data describing the clocks and resets which are specific to the
R9A07G044{L,C} SoCs. The identifier r9a07g044 (without a final letter)
is used to indicate that both SoCs are supported.
clk_set_rate() and clk_get_rate() are implemented only for the clocks
that are actually used in u-boot.
The CPG driver is marked with DM_FLAG_PRE_RELOC to ensure that its bind
function is called before the SCIF (serial port) driver is probed. This
is required so that we can de-assert the relevant reset signal during
the serial driver probe function.
Paul Barker [Mon, 16 Oct 2023 09:25:23 +0000 (10:25 +0100)]
serial: sh: Fix compile error when lacking HSCIF support
If we attempt to compile serial_sh.c for a system which lacks HSCIF
support (e.g. R8A7740), we see the following compilation error:
In file included from drivers/serial/serial_sh.c:20:
drivers/serial/serial_sh.c: In function ‘sh_serial_init_generic’:
drivers/serial/serial_sh.h:429:35: warning: implicit declaration of function ‘sci_HSSRR_out’; did you mean ‘sci_SCSCR_out’? [-Wimplicit-function-declaration]
429 | #define sci_out(port, reg, value) sci_##reg##_out(port, value)
| ^~~~
drivers/serial/serial_sh.c:62:17: note: in expansion of macro ‘sci_out’
62 | sci_out(port, HSSRR, HSSRR_SRE | HSSRR_SRCYC8);
| ^~~~~~~
To fix this, only try to support access to the HSSRR register for SoCs
where it actually exists.
Support for the RZ/G2L will be introduced in following patches, which
selects CONFIG_RCAR_64 but does not have HSCIF interfaces, so check for
CONFIG_RCAR_GEN2 || CONFIG_RCAR_GEN3 || CONFIG_RCAR_GEN4 to determine if
HSCIF is present.
Fixes: bbe36e29ca2c ('serial: sh: Add HSCIF support for R-Car SoC') Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Cc: Hai Pham <hai.pham.ud@renesas.com> Cc: Simon Glass <sjg@chromium.org> Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Ye Li [Tue, 25 Jul 2023 08:08:55 +0000 (10:08 +0200)]
serial: lpuart: Enable IPG clock
Current codes only ennable the PER clock. However on iMX8 the LPUART
also needs IPG clock which is an LPCG. Should not depend on the default
LPCG setting.
Signed-off-by: Ye Li <ye.li@nxp.com> Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Sébastien Szymanski <sebastien.szymanski@armadeus.com>
Marek Vasut [Sat, 15 Jul 2023 18:24:16 +0000 (20:24 +0200)]
ARM: dts: imx: Switch USB1 port control to GPIO on Data Modul i.MX8M Plus eDM SBC
The USB_PWR signal operation is not reliable on this DWC3 controller
instance in case the signal is active high. Switch to GPIO control,
which always behaves correctly. Perform the change in u-boot extras
until this hits Linux upstream.
Chris Packham [Fri, 13 Oct 2023 03:00:11 +0000 (16:00 +1300)]
arm: mvebu: AC5/AC5X: Disable SMBIOS
The RD-AC5X doesn't make use of EFI or SMBIOS. Recently we started seeing
boot failures such as
WARNING: SMBIOS table_address overflow 27f60f020
Failed to write SMBIOS table
initcall failed at event 10/(unknown) (err=-22)
### ERROR ### Please RESET the board ###
The error is because the physical address of the RAM on the AC5X SoC is
above the 32GiB boundary. As we don't need SMBIOS or EFI this can be
safely disabled.
Signed-off-by: Chris Packham <judge.packham@gmail.com> Reviewed-by: Stefan Roese <sr@denx.de>
Josua Mayer [Sun, 8 Oct 2023 14:58:03 +0000 (16:58 +0200)]
arm: mvebu: clearfog: read number of ddr channels from tlv data
Extend the existing tlv vendor extension used for ram size by one byte to
also store the number of ddr channels.
The length of the tlv entry can indicate whether the new information is
present. If not default to single channel.
Signed-off-by: Josua Mayer <josua@solid-run.com> Reviewed-by: Stefan Roese <sr@denx.de>
Chris Packham [Tue, 3 Oct 2023 03:57:39 +0000 (16:57 +1300)]
Revert "arm: mvebu: x240: Use i2c-gpio instead of built in controller"
This reverts commit 5c1c6b7306f2b4c0fd50c7cb5d757e245b93606e. The reason
for switching to i2c-gpio was due to an issue we were seeing in the
Linux kernel where the CPU would lock up on certain adverse I2C bus
conditions. We were never able to reproduce the lockup in U-Boot but
assumed that was probably just luck.
Since then we have discovered that the lock up was due to the I2C
transaction offload engine in the I2C controller not coping with the
adverse bus conditions (basically it thinks there's another master and
waits for a STOP condition that never comes). U-Boot doesn't use the I2C
offload feature so is not susceptible to the lockup.
We can therefore safely return to using the built-in I2C controller.
Signed-off-by: Chris Packham <judge.packham@gmail.com> Reviewed-by: Stefan Roese <sr@denx.de>
Chris Packham [Tue, 3 Oct 2023 03:57:38 +0000 (16:57 +1300)]
arm: mvebu: x240: Disable SMBIOS
The x240 doesn't make use of EFI or SMBIOS. Recently we started seeing
boot failures such as
WARNING: SMBIOS table_address overflow 23f60c020
Failed to write SMBIOS table
initcall failed at event 10/(unknown) (err=-22)
### ERROR ### Please RESET the board ###
The error is because the physical address of the RAM on the AC5X SoC is
above the 32GiB boundary. As we don't need SMBIOS or EFI this can be
safely disabled.
Signed-off-by: Chris Packham <judge.packham@gmail.com> Reviewed-by: Stefan Roese <sr@denx.de>
Teresa Remmet [Thu, 17 Aug 2023 08:57:11 +0000 (10:57 +0200)]
board: phytec: phycore_imx8mp: Add 4000MTS RAM timings based on PCB rev
Starting with PCB revision 3 we can safely make use of higher RAM
frequency again. Make use of the EEPROM detection to determine the
revision and use the updated RAM timings for new SoMs.
Due to PCB layout constraints in PCB revisions until including 1549.2,
a RAM frequency of 2 GHz can cause rare instabilities. Set the RAM
frequency to 1.5 GHz to achieve a stable system under all conditions.
Teresa Remmet [Thu, 17 Aug 2023 08:57:06 +0000 (10:57 +0200)]
board: phytec: Add common PHYTEC SoM detection
Recent shipped PHYTEC SoMs come with an i2c EEPROM containing
information about the hardware such as board revision and variant.
This can be used for RAM detection and loading device tree overlays
during kernel start.
Tony Dinh [Sat, 26 Aug 2023 03:33:29 +0000 (20:33 -0700)]
arm: kirkwood: Add support for ZyXEL NSA325 board
ZyXEL NSA325 specifications:
Marvell Kirkwood 88F6282 SoC
1.6 GHz CPU
1x GBE LAN port (Marvell MV88E1318)
512 MB RAM
128 MB Eon NAND, SLC
I2C
1x USB 3.0 (on PCIe bus)
2x USB 2.0
2x SATA (hot swap slots)
Serial console
Signed-off-by: Tony Dinh <mibodhi@gmail.com> Reviewed-by: Stefan Roese <sr@denx.de>
The cn9130.dtsi defines a pinctrl node for SPI1 (until recently it was
mislabeled as spi0). Use this instead of having a duplicate definition
with a different label.
Signed-off-by: Chris Packham <judge.packham@gmail.com> Reviewed-by: Stefan Roese <sr@denx.de>
Chris Packham [Sun, 20 Aug 2023 23:31:04 +0000 (11:31 +1200)]
ARM64: dts: marvell: cn9310: Use appropriate label for spi1 pins
The CN9130-DB uses the SPI1 interface but had the pinctrl node labelled
as "cp0_spi0_pins". Use the label "cp0_spi1_pins" and update the node
name to "cp0-spi-pins-1" to avoid confusion with the pinctrl options for
SPI0.
Signed-off-by: Chris Packham <judge.packham@gmail.com> Reviewed-by: Stefan Roese <sr@denx.de>
Eduard Strehlau [Tue, 10 Oct 2023 14:14:12 +0000 (11:14 -0300)]
smegw01: Remove misuse of CONFIG_ENV_IS_NOWHERE
When using a list of writeable variables, the initial values come
from the built-in default environment since commit 5ab81058364b ("env:
Complete generic support for writable list").
Remove unnecessary misuse of CONFIG_ENV_IS_NOWHERE as default environment.
Based on the fix done by commit b16fd7f75f6d ("imx6q: acc: Remove misuse
of env is nowhere driver").
Signed-off-by: Eduard Strehlau <eduard@lionizers.com> Signed-off-by: Fabio Estevam <festevam@denx.de>
Fabio Estevam [Mon, 9 Oct 2023 13:15:35 +0000 (10:15 -0300)]
usb: ehci: mxs: Use regulator_set_enable_if_allowed()
Since commit 4fcba5d556b4 ("regulator: implement basic reference
counter") the return value of regulator_set_enable() may be EALREADY or
EBUSY for fixed/GPIO regulators.
Switch to using the more relaxed regulator_set_enable_if_allowed() to
continue if regulator already was enabled or disabled.
This fixes the following error when running the 'ums' command:
Extend the padding process of u-boot-nand.imx target by adding 10k bytes
of zeros to the end of the binary using the 'dd' command.
The existing padding method did not generate a functional binary,
as discussed in more detail in this thread [1]. Instead, we adopt the
end-padding calculation method documented in 'board/doc/colibri_imx7.rst'
as a reference, which is relevant for iMX7 with NAND storage.
Adding 10k bytes of zeros provides an approximate value that makes the
proper padding for these NAND devices.
Hiago De Franco [Mon, 2 Oct 2023 11:57:49 +0000 (08:57 -0300)]
toradex: colibri_imx7: Enable nand/emmc detection and set boot variant
Add detection of eMMC vs NAND devices on the Colibri iMX7
board. A GPIO is configured to detect the presence of an on-board resistor
that is configured differently based on the flash memory used. Depending on
the detection result, the 'variant' environment variable is set to '-emmc'
or cleared, indicating the type of storage device.
This enhancement improves variant detection during system initialization
through USB recovery mode, where U-Boot is loaded directly to RAM. This
allows variant detection for an accurate device tree selection.
board: toradex: verdin-imx8mm: set fixed LPDDR4 refresh rate as per errata ERR050805
Update lpddr4 configuration and training using updated spreadsheet and
tools from NXP using data from previous spreadsheet and verified
toward datasheet:
The most relevant update is related to errata ERR050805:
"DRAM: Controller automatic derating logic may not work when
the LPDDR4 memory temperature is above 85 °C at initialization"
Other relevant fixes:
- DRAMTMG7 register: corrected calculation of T_CKPDX parameter
(equal to tCKCKEH for LPDDR4)
- RANKCTL register: corrected calculations for ODTLon and ODTLoff
to follow the JEDEC specification
- ADDRMAP7 register: added support for 17-row devices
As per errata ERR050805:
An issue exists with the automatic derating logic of the DDR
controller that only samples the LPDDR4 MR4 register when the
Temperature Update Flag (TUF) field (MR4[7] ) is 1’b1. If the
LPDDR4 memory is initialized and starts operation above 85 °C
(MR4[2:0] > 3’b011), the MR4 Temperature Update Flag (TUF) will
not be set. The DDR Controller will therefore not automatically
adjust the memory refresh rate or de-rate memory timings based
on the LPDDR4 memory temperature. This may cause the controller
incorrectly setting the refresh period, potentially cause the
LPDDR4 memory losing data contents and lead to possible data
integrity issues above 85 °C.
Errata provides three possible workaround options, while option 2
is the most reasonable:
Disable the automatic derating logic of the DDR controller and
apply fixed x2 refresh rate (0.5x refresh). This option is
suitable for designs that are expected to boot at or above 85 °C
and memory’s MR4[2:0] (Refresh Rate) DOES NOT report the following
conditions:
3b101: 0.25x refresh, no de-rating
3b110: 0.25x refresh, with de-rating
3b111: SDRAM High temperature operating limit exceeded
mx8m: csf.sh: pad csf blob for u-boot.itb to CSF_SIZE minus IVT header
When built with CONFIG_IMX_HAB, the full FIT image, including stuff
tacked on beyond the end of the fdt structure, is expected to be (fdt
size rounded up to 0x1000 boundary)+CONFIG_CSF_SIZE.
Now, when the FIT image is loaded from a storage device, it doesn't
really matter that the flash.bin that gets written to target isn't
quite that big - we will just load some garbage bytes that are never
read or used for anything. But when flash.bin is uploaded via uuu,
it's important that we actually serve at least as many bytes as the
target expects, or we will hang in rom_api_download_image().
Extend the logic in the csf.sh script so that the csf blob is padded
to CONFIG_CSF_SIZE minus the size of the IVT header.
imx: spl_imx_romapi: avoid tricky use of spl_load_simple_fit() to get full FIT size
Currently, spl_imx_romapi uses a somewhat tricky workaround for the
fact that a FIT image with external data doesn't directly allow one to
know the full size of the file: It does a dummy spl_load_simple_fit(),
having the ->read callback remember the largest offset requested, and
then does a last call to rom_api_download_image() to fetch the
remaining part of the full FIT image.
We can avoid that by just keeping track of how much we have downloaded
already, and if the ->read() requests something outside the current
valid buffer, fetch up to the end of the current request.
The current method also suffers from not working when CONFIG_IMX_HAB
is enabled: While in that case u-boot.itb is not built with external
data, so the fdt header does contain the full size of the dtb
structure. However, it does not account for the extra CONFIG_CSF_SIZE
added by board_spl_fit_size_align(). And also, the data it hands out
during the first dummy spl_load_simple_fit() is of course garbage, and
wouldn't pass the verification.
So we really need to call spl_load_simple_fit() only once, let that
figure out just how big the FIT image is (including whatever data, CSF
or "ordinary" external data, has been tacked on beyond the fdt
structure), and always provide valid data from the ->read callback.
This only affects the CONFIG_SPL_LOAD_FIT case - I don't have any
hardware or experience with the CONFIG_SPL_LOAD_IMX_CONTAINER case, so
I leave that alone for now.
The hab signing script doc/imx/habv4/csf_examples/mx8m/csf.sh does
fdtget -t x u-boot.dtb /binman/imx-boot/uboot offset
to figure out the offset of u-boot.itb inside flash.bin. That works
fine for imx8mm, imx8mn, imx8mq, but fails for imx8mp because in that
case 'uboot' is merely a label and not actually the node name.
Homogenize these cases and make imx8mp the same as the other imx8m*
variants. The binman type is explicitly given and no longer derived
from the node name, and the csf.sh script will work for all four SOCs.
Tim Harvey [Thu, 24 Aug 2023 19:03:56 +0000 (12:03 -0700)]
arm: dts: imx8m: move CAAM nodes into common u-boot.dtsi
Move the crypto and sec_jr* nodes from board-specific
u-boot.dtsi files into the common files. Additionally protect the
nodes with ifdef CONFIG_FSL_CAAM as they don't serve any purpose if
that is not enabled.
Signed-off-by: Tim Harvey <tharvey@gateworks.com> Reviewed-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Tim Harvey [Thu, 24 Aug 2023 19:01:43 +0000 (12:01 -0700)]
arm: dts: imx8mp: move firmware/optee node to common imx8mp-u-boot.dtsi
Move the firmware/optee node to the common imx8mp-u-boot.dtsi and
protect it with an ifdef CONFIG_OPTEE as it is a meaningless node
without the optee driver enabled.
Signed-off-by: Tim Harvey <tharvey@gateworks.com> Reviewed-by: Fabio Estevam <festevam@denx.de>
Tim Harvey [Thu, 24 Aug 2023 19:01:42 +0000 (12:01 -0700)]
arm: dts: imx8mm: move firmware/optee node to common imx8mm-u-boot.dtsi
Move the firmware/optee node to the common imx8mm-u-boot.dtsi and
protect it with an ifdef CONFIG_OPTEE as it is a meaningless node
without the optee driver enabled.
Tim Harvey [Tue, 15 Aug 2023 22:01:15 +0000 (15:01 -0700)]
board: gateworks: venice: updates for imx8mp-venice-gw74xx revB PCB
Update the imx8mp-venice-gw74xx for revB:
- add CAN1
- add TIS-TPM on SPI2
- add FAN controller
- fix PMIC I2C bus (revA PMIC I2C was non-functional so no need for
backward compatible option)
- M2 socket GPIO's moved
Tim Harvey [Tue, 15 Aug 2023 22:01:14 +0000 (15:01 -0700)]
board: gateworks: venice: add imx8mm-gw7905-0x support
The Gateworks imx8mm-venice-gw7905-0x consists of a SOM + baseboard.
The GW700x SOM contains the following:
- i.MX8M Mini SoC
- LPDDR4 memory
- eMMC Boot device
- Gateworks System Controller (GSC) with integrated EEPROM, button
controller, and ADC's
- RGMII PHY
- PMIC
- SOM connector providing:
- FEC GbE MII
- 1x SPI
- 2x I2C
- 4x UART
- 2x USB 2.0
- 1x PCI
- 1x SDIO (4-bit 3.3V)
- 1x SDIO (4-bit 3.3V/1.8V)
- GPIO
The GW7905 Baseboard contains the following:
- GPS
- microSD
- off-board I/O connector with I2C, SPI, GPIO
- EERPOM
- PCIe clock generator
- 1x full-length miniPCIe socket with PCI/USB3 (via mux) and USB2.0
- 1x half-length miniPCIe socket with USB2.0 and USB3.0
- USB 3.0 HUB
- USB Type-C with USB PD Sink capability and peripheral support
- USB Type-C with USB 3.0 host support
Tim Harvey [Tue, 15 Aug 2023 22:01:13 +0000 (15:01 -0700)]
board: gateworks: venice: add imx8mp-gw73xx-2x support
The Gateworks imx8mp-venice-gw73xx-2x consists of a SOM + baseboard.
The GW702x SOM contains the following:
- i.MX8M Plus SoC
- LPDDR4 memory
- eMMC Boot device
- Gateworks System Controller (GSC) with integrated EEPROM, button
controller, and ADC's
- PMIC
- SOM connector providing:
- eQoS GbE MII
- 1x SPI
- 2x I2C
- 4x UART
- 2x USB 3.0
- 1x PCI
- 1x SDIO (4-bit 3.3V)
- 1x SDIO (4-bit 3.3V/1.8V)
- GPIO
The GW73xx Baseboard contains the following:
- 1x RJ45 GbE (eQoS from SOM)
- 1x RJ45 GbE (PCI)
- off-board I/O connector with MIPI-CSI (3-lane), MIPI-DSI (4-lane),
- off-board I/O connector with RS232/RS485
- off-board I/O connector with SPI
- off-board I/O connector with I2C, UART, and GPIO
I2C, I2S and GPIO
- microSD (1.8V/3.3V)
- GPS
- Accelerometer
- EERPOM
- USB 3.0 Hub
- Front Panel bi-color LED
- re-chargeable battery (for RTC)
- PCIe clock generator
- PCIe switch
- on-board 802.11abgnac 1x1 WiFi and Bluetooth 5.2
- 1x USB Type-A host socket with USB 3.0 support
- 1x USB OTG with USB 2.0 support
- 2x MiniPCIe socket with PCI and USB 2.0
- 1x MiniPCIe socket with SIM, PCI/USB 3.0 (mux), and USB 2.0
- Wide range DC input supply
Tim Harvey [Tue, 15 Aug 2023 22:01:12 +0000 (15:01 -0700)]
board: gateworks: venice: add imx8mp-gw72xx-2x support
The Gateworks imx8mp-venice-gw72xx-2x consists of a SOM + baseboard.
The GW702x SOM contains the following:
- i.MX8M Plus SoC
- LPDDR4 memory
- eMMC Boot device
- Gateworks System Controller (GSC) with integrated EEPROM, button
controller, and ADC's
- PMIC
- SOM connector providing:
- eQoS GbE MII
- 1x SPI
- 2x I2C
- 4x UART
- 2x USB 3.0
- 1x PCI
- 1x SDIO (4-bit 3.3V)
- 1x SDIO (4-bit 3.3V/1.8V)
- GPIO
The GW72xx Baseboard contains the following:
- 1x RJ45 GbE (eQoS from SOM)
- 1x RJ45 GbE (PCI)
- off-board I/O connector with MIPI-CSI (3-lane), MIPI-DSI (4-lane),
- off-board I/O connector with RS232/RS485
- off-board I/O connector with SPI
- off-board I/O connector with I2C, UART, and GPIO
I2C, I2S and GPIO
- microSD (1.8V/3.3V)
- GPS
- Accelerometer
- EERPOM
- USB 3.0 Hub
- Front Panel bi-color LED
- re-chargeable battery (for RTC)
- PCIe clock generator
- PCIe switch
- 1x USB Type-A host socket with USB 3.0 support
- 1x USB OTG with USB 2.0 support
- 1x MiniPCIe socket with PCI and USB 2.0
- 1x MiniPCIe socket with SIM, PCI/USB 3.0 (mux), and USB 2.0
- Wide range DC input supply
Tim Harvey [Tue, 15 Aug 2023 22:01:11 +0000 (15:01 -0700)]
board: gateworks: venice: add imx8mp-gw71xx-2x support
The Gateworks imx8mp-venice-gw71xx-2x consists of a SOM + baseboard.
The GW702x SOM contains the following:
- i.MX8M Plus SoC
- LPDDR4 memory
- eMMC Boot device
- Gateworks System Controller (GSC) with integrated EEPROM, button
controller, and ADC's
- PMIC
- SOM connector providing:
- eQoS GbE MII
- 1x SPI
- 2x I2C
- 4x UART
- 2x USB 3.0
- 1x PCI
- 1x SDIO (4-bit 3.3V)
- 1x SDIO (4-bit 3.3V/1.8V)
- GPIO
The GW71xx Baseboard contains the following:
- 1x RJ45 GbE (eQoS from SOM)
- off-board I/O connector with I2C, SPI, UART, and GPIO
- Front Panel bi-color LED
- re-chargeable battery (for RTC)
- PCIe clock generator
- 1x USB Type-C connector supporting USB 2.0 host mode with VBUS
- 1x MiniPCIe socket with SIM, PCI/USB 3.0 (mux), and USB 2.0
- GPS
- Accelerometer
- EERPOM
- Wide range DC input supply
projects / u-boot.git / log