Signed-off-by: Tom Rini <trini@konsulko.com>

J721e SK has been broken since at least March 2022.

The main-navss and mcu-navss nodes were renamed and this caused the
A72 SPL to fail early in the boot even before the serial port was
enabled. Fix this.

A later patch series between v2022.07 and v2022.10 additionally broke
boot on this board by introducing hbmc nodes which are not present on
this board. The right fix is to disable these by default in the SOC
dtsi file, but for now we can also disable them in the u-boot dtsi.

With both these fixed, we can now boot the j721e SK board fully from
mainline u-boot.

Fixes: 58d61fb5 ("arm: dts: k3-j721e-sk: Add initial A72 specific dts support")
Fixes: 297daac4 ("arm: dts: k3-j721e-mcu-wakeup: Add HyperBus Controller node")
Reported-by: Anand Gadiyar <gadiyar@ti.com>
Signed-off-by: Sinthu Raja <sinthu.raja@ti.com>
[gadiyar@ti.com: update commit description]
Signed-off-by: Anand Gadiyar <gadiyar@ti.com>
Cc: Bryan Brattlof <bb@ti.com>

Originally, the mmc aliases node was present in imx6qdl-pico.dtsi.

After the sync with Linux in commit d0399a46 ("imx6dl/imx6qdl:
synchronise device trees with linux"), the aliases node is gone as
the upstream version does not have it.

This causes a boot regression in which the eMMC card cannot be found anymore.

Fix it by passing the alias node in the u-boot.dtsi file to
restore the original behaviour where the eMMC (esdhc3) was
mapped to mmc0.

Fixes: d0399a46 ("imx6dl/imx6qdl: synchronise device trees with linux")
Signed-off-by: Fabio Estevam <festevam@denx.de>

Fixes for 2023.04
------------------

CI: https://source.denx.de/u-boot/custodians/u-boot-imx/-/pipelines/15831

- fix for imx8mn_bsh_smm_s2

A condition in the rk3399 RAM initialization code used the old
CONFIG_RAM_RK3399_LPDDR4 constant name. This commit changes the
condition to use the correct CONFIG_RAM_ROCKCHIP_LPDDR4 constant.

Reviewed-by: Simon Glass <sjg@chromium.org>

Pull request for efi-2023-04-rc6

Documentation:

* describe skipping triggering a pipeline in Gitlab

UEFI:

* correct shortening of device-paths for boot options

Assigning the value of a variable to itself should be avoided.

Addresses-Coverity-ID: 451089 ("Evaluation order violation")
Fixes: 180b7118 ("efi_loader: fix device-path for USB devices")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

We use short device-paths in boot options so that a file on a block device
can be found independent of the port into which the device is plugged.

Usb() device-path nodes only contain port and interface information and
therefore cannot identify a block device.
UsbWwi() device-path nodes contain the serial number of USB devices.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

'git push -o ci.skip' can be used to push to Gitlab without triggering a
pipeline.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>

%s/supporedt/supported/

Fixes: edca8cf7 ("Convert CONFIG_SCSI_AHCI_PLAT et al to Kconfig")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

Fixes for buildman and sysreset

The Linux kernel device tree already specifies the device to be used for
boot console output with a stdout-path property under /chosen.

Commit 36b661dc ("Merge branch 'next'") re-added the console
setting that commit bede82f7 ("configs: imx8mn_bsh_smm_s2: remove
console from bootargs") had previously removed.

Fixes: 36b661dc ("Merge branch 'next'")
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Reviewed-by: Fabio Estevam <festevam@denx.de>

It should return -EINPROGRESS if successful otherwise sysreset-uclass
will continue to the next sysreset device.

Signed-off-by: Jonathan Liu <net147@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

The toolchain test causes the settings file to be overwritten, which is
annoying for local development. Fix it by passing None as the filename.

Signed-off-by: Simon Glass <sjg@chromium.org>

After the conversion to DM_SERIAL in commit 01f372d8 ("udoo_neo:
Select DM_SERIAL and drop iomux board level init") the SPL log is gone
and the U-Boot proper log becomes incomplete:

Core:  80 devices, 18 uclasses, devicetree: separate
MMC:   FSL_SDHC: 1, FSL_SDHC: 2
Loading Environment from MMC... OK
In:    serial@2020000
Out:   serial@2020000
Err:   serial@2020000
Net:   eth0: ethernet@2188000
Hit any key to stop autoboot:  0

Introduce the u-boot.dtsi file that passes the u-boot,dm-pre-reloc
properties to the relevant nodes so that UART can be used early in SPL.

With this change, the complete SPL and U-Boot messages are seen again.

Signed-off-by: Fabio Estevam <festevam@denx.de>

- Merge a regression fix (for an issue that we raised post v2023.01)
  with cli_getch(), and include a test now.

The second call to cli_ch_process() is in the wrong place, meaning that
the one of the characters of an invalid escape sequence is swallowed
instead of being returned.

Fix the bug and add a test to cover this.

This behaviour matches that of the code before cli_getch() was
introduced. This was verified on the commit before b08e9d4b i.e.:

   7d850f85 ("sandbox: Enable mmc command and legacy images")

Signed-off-by: Simon Glass <sjg@chromium.org>
Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

This function does not behave as expected when unknown escape sequences
are sent to it:

- it fails to store (and thus echo) the last character of the invalid
  sequence
- it fails to set esc_len to 0 when it finishes emitting the invalid
  sequence, meaning that the following character will appear to be part
  of a new escape sequence
- it processes the first character of the rejected sequence as a valid
  character, just starting the sequence all over again

The last two bugs conspire to produce an "impossible condition #876"
message which is the main symptom of this behaviour.

Fix these bugs and add a test to verify the behaviour.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

Signed-off-by: Tom Rini <trini@konsulko.com>

Rsync all defconfig files using moveconfig.py

Signed-off-by: Tom Rini <trini@konsulko.com>

- A series of minor cleanups to DISTRO_DEFAULTS and BOOTSTD so that the
  rk3399 bootstd migration can be complete and functional now, and make
  future migrations easier.

The defined altbootcmd was specific to distro_bootcmd which is not
longer in use on these platforms, so drop it.

Tested-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>

When we do not enable DISTRO_DEFAULTS (generally, to get distro_bootcmd)
we instea do want to imply BOOTSTD_DEFAULTS so that when using bootstd
the general distro boot functionality will still work.

Signed-off-by: Tom Rini <trini@konsulko.com>

These board have moved to standard boot but the old 'distro_bootcmd'
command is still active. Disable DISTRO_DEFAULTS to fix this.

Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Vagrant Cascadian <vagrant@debian.org>

These two features use a lot of common options. Move them into a common
CONFIG to reduce duplication.

Use 'select' for most options since these are things that boards aren't
supposed to override. For now it is not possible to disable
BOOT_DEFAULTS but we may take another look later.

Note that five options use 'imply' to match existing behaviour.

Signed-off-by: Simon Glass <sjg@chromium.org>
[trini: Rework a bit so we don't grow so many platforms unintentionally]
Signed-off-by: Tom Rini <trini@konsulko.com>

Ramdisk relocation requires LMB, so enable it automatically to avoid
build errors.

Signed-off-by: Simon Glass <sjg@chromium.org>

This relates to booting so move it in to that Kconfig file, before
changing it.

Signed-off-by: Simon Glass <sjg@chromium.org>

Unfortunately the IRAM used to stash the bootstage records in TPL
becomes inaccessible after SPL runs. Presumably this is because of ATF
taking it over.

We could move the stash to another address in SPL, before passing it to
U-Boot proper. But it seems easier to wait until we have support for
standard passage[1] which should not be too far away.

For now, disable it in TPL and SPL.

[1] https://patchwork.ozlabs.org/project/uboot/cover/


    20220117150428.1580273-1-sjg@chromium.org/

Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Vagrant Cascadian <vagrant@debian.org>

- x86: Bug fixes of previous BayTrail platform CONFIG_TEXT_BASE changes

With recent CONFIG_TEXT_BASE changes, there are inconsistencies between
several settings.

Adjust CONFIG_SYS_MONITOR_LEN to allow more code space. Move the MRC
cache out of the way too.

Fixes: e23cae30 ("x86: som-db5800-som-6867: Adjust CONFIG_TEXT_BASE")
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

With recent CONFIG_TEXT_BASE changes, there are inconsistencies between
several settings.

Adjust CONFIG_SYS_MONITOR_LEN to allow more code space. Move the MRC
cache out of the way too.

Fixes: 5d1c8342 ("x86: dfi-bt700: Adjust CONFIG_TEXT_BASE")
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

With recent CONFIG_TEXT_BASE changes, there are inconsistencies between
several settings.

Adjust CONFIG_SYS_MONITOR_LEN to allow more code space. Move the MRC
cache out of the way too.

Fixes: 388f93f9 ("x86: conga-qeval20-qa3-e3845: Adjust CONFIG_TEXT_BASE")
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>

With recent CONFIG_TEXT_BASE changes, there are inconsistencies between
several settings.

Adjust CONFIG_SYS_MONITOR_LEN to allow more code space. Move the MRC
cache out of the way too.

Fixes: f38be308 ("x86: bayleybay: Adjust CONFIG_TEXT_BASE")
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

With recent CONFIG_TEXT_BASE changes, there are inconsistencies between
several settings.

Adjust CONFIG_SYS_MONITOR_LEN to allow more code space. Move the MRC
cache out of the way too.

Add documentation on how to make this change safely.

Fixes: 66e2c665 ("x86: minnowmax: Adjust CONFIG_TEXT_BASE")
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

Pull request for efi-2023.04-rc5

UEFI:

* Create unique device paths for USB devices with the same vendor
  and product id.

EFI device paths for block devices must be unique. If a non-unique device
path is discovered, probing of the block device fails.

Currently we use UsbClass() device path nodes. As multiple devices may
have the same vendor and product id these are non-unique. Instead we
should use Usb() device path nodes. They include the USB port on the
parent hub. Hence they are unique.

A USB storage device may contain multiple logical units. These can be
modeled as Ctrl() nodes.

Reported-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

* Add the definitions for Ctrl() device path nodes.
* Implement Ctrl() nodes in the device path to text protocol.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

- Fixes for booting newer revs of the SoC in the Raspberry Pi 4
- Propagate some firmware DT properties to the loaded DT
- Update the Zero2W upstream DT name

Newer firmware can manage the SDCDIV clock divisor register, allowing
the divisor to scale with the core as necessary.

Leverage this ability if the firmware supports it.

Adapted from the following raspberrypi Linux kernel commit:

  bcm2835-sdhost: Firmware manages the clock divisor
  https://github.com/raspberrypi/linux/commit/08532d242d7702ae0add95096aa49c5e96e066e2



Signed-off-by: Vincent Fazio <vfazio@xes-inc.com>
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>

In rpi-firmware 25e2b597ebfb2495eab4816a276758dcc6ea21f1,
the GET_CLOCK_RATE mailbox property was changed to return the last
value set by SET_CLOCK_RATE.

https://github.com/raspberrypi/firmware/issues/1619#issuecomment-917025502



Due to this change in firmware behavior, bcm2835_get_mmc_clock now
returns a clock rate of zero since we do not issue SET_CLOCK_RATE.
This results in degraded MMC performance.

SET_CLOCK_RATE fixes the clock to a specific value and disables scaling
so is not an ideal solution.

Instead, fallback to GET_MAX_CLOCK_RATE in bcm2835_get_mmc_clock if
GET_CLOCK_RATE returns zero.

Signed-off-by: Vincent Fazio <vfazio@xes-inc.com>
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>