Eugen Hristev [Mon, 15 May 2023 09:59:49 +0000 (12:59 +0300)]
phy: rockchip-inno-usb2: add initial support for rk3588 PHY
Add initial support for the rk3588 PHY variant.
The lookup for the host-port reg inside the struct now does a do {} while()
instead of a while() {} in order to allow a first check for reg == 0.
Reviewed-by: Kever Yang <kever.yang@rock-chips.com> Co-developed-by: Frank Wang <frank.wang@rock-chips.com> Signed-off-by: Frank Wang <frank.wang@rock-chips.com> Signed-off-by: Eugen Hristev <eugen.hristev@collabora.com>
Eugen Hristev [Mon, 15 May 2023 09:59:48 +0000 (12:59 +0300)]
phy: remove phy-supply related code
phy-supply is now handled at uclass level. Remove it from the drivers that
implement it at the driver level.
Acked-by: Neil Armstrong <neil.armstrong@linaro.org> Suggested-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Eugen Hristev <eugen.hristev@collabora.com>
Eugen Hristev [Mon, 15 May 2023 09:59:47 +0000 (12:59 +0300)]
phy: add support for phy-supply
Some phys require a phy-supply property that is a phandle to a regulator
that needs to be enabled for phy operations.
Implement basic supply lookup, enable and disabling, if DM_REGULATOR is
available.
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
[jonas@kwiboo.se:
use regulator_set_enable_if_allowed and disable if power_on ops fails] Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Eugen Hristev <eugen.hristev@collabora.com>
Eugen Hristev [Mon, 15 May 2023 09:59:45 +0000 (12:59 +0300)]
ARM: dts: rockchip: rk3588-rock-5b-u-boot: add USB 2.0 host
Add USB 2.0 host nodes and PHYs.
Reviewed-by: Kever Yang <kever.yang@rock-chips.com> Co-developed-by: William Wu <william.wu@rock-chips.com> Signed-off-by: William Wu <william.wu@rock-chips.com> Signed-off-by: Eugen Hristev <eugen.hristev@collabora.com>
Tom Rini [Tue, 16 May 2023 15:23:30 +0000 (11:23 -0400)]
Merge tag 'efi-2023-07-rc3' of https://source.denx.de/u-boot/custodians/u-boot-efi
Pull request efi-2023-07-rc3
Documentation:
* update the description of signature algorithms
UEFI:
* fix unaligned access to GUID in HII database protocol
* fix launching EFI binaries loaded via semihosting
* fix filling of file path in loaded image protocol for non-block devices
Tom Rini [Tue, 16 May 2023 15:16:42 +0000 (11:16 -0400)]
Merge branch '2023-05-15-assorted-bugfixes'
- Merge in a long-standing fix for some exynos platforms, correct a
Kconfig description, fix some env issues, fix an issue in
devfdt_get_addr_size_index_ptr and look for "panel-timings" not
"panel-timing" per upstream binding.
drivers: core: ofnode: fix typo in panel timing decode
In case where a single timing resolution is implemented in the
device-tree, the property is named "panel-timing", as specify
in Linux kernel binding file:
# Display Timings
panel-timing:
description:
Most display panels are restricted to a single resolution and
require specific display timings. The panel-timing subnode expresses those
timings.
$ref: panel-timing.yaml#
display-timings:
description:
Some display panels support several resolutions with different timings.
The display-timings bindings supports specifying several timings and
optionally specifying which is the native mode.
$ref: display-timings.yaml#
Christophe Leroy [Thu, 11 May 2023 06:16:49 +0000 (08:16 +0200)]
envtools lack extra settings since commit 86b9c3e4e4 ("env: Allow U-Boot scripts to be placed in
After converting my targets from CFG_EXTRA_ENV_SETTINGS to
CONFIG_EXTRA_ENV_TEXT as suggested by Tom, I discovered that
fw_setenv doesn't set the entire defaut environment anymore.
I tried to fix it with the below patch, but it fails qemu-x86 CI test,
see https://source.denx.de/u-boot/custodians/u-boot-mpc8xx/-/pipelines/16326
That's the only CI test that fails AFAICS.
Could you help with a solution ? This needs to be fixed.
After converting some targets from CFG_EXTRA_ENV_SETTINGS to
CONFIG_EXTRA_ENV_TEXT, default environment embedded in
fw_env tool missed all extra settings.
Commit 86b9c3e4e4 ("env: Allow U-Boot scripts to be placed in
a .env file") restricted the inclusion of the content of that
file to builds without USE_HOSTCC.
But as mentionned in commit 79fc0c5f49 ("tools/env: cross-compile
fw_printenv without setting HOSTCC"), HOSTCC and USE_HOSTCC are
kept for code re-use.
Remove the restricting so that settings included in a .env
file are also added to fw_env tool.
Fixes: 86b9c3e4e4 ("env: Allow U-Boot scripts to be placed in a .env file") Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Commit 4a3ea75de4c5 ("Revert "mmc: sdhci: set to INT_DATA_END when
there are data"") reverted the alternative fix that was added for
Exynos 4 devices, causing an error when trying to boot from an sdcard:
<...>
Loading Environment from MMC... sdhci_send_command: Timeout for status update!
mmc fail to send stop cmd
<...>
Re-add the quirk to allow booting from sdcards again.
Nuno Sá [Thu, 11 May 2023 11:19:50 +0000 (13:19 +0200)]
mtd: cfi: respect reg address length
flash_get_size() will get the flash size from the device itself and go
through all erase regions to read protection status. However, the device
mappable region (eg: devicetree reg property) might be lower than the
device full size which means that the above cycle will result in a data
bus exception. This change fixes it by reading the 'addr_size' during
probe() and also use that as one possible upper limit.
Revert "spi: zynq_qspi: Use dummy buswidth in dummy byte calculation"
This reverts commit e09784728689de7949d4cdd559a9590e0bfcc702. The
commit wrongly divides the dummy bytes by dummy bus width to calculate
the dummy bytes. The framework already converts the dummy cycles to the
number of bytes and the controller use the SPI flash command to
determine the dummy cycles via the address width.
Michal Simek [Wed, 12 Apr 2023 14:30:27 +0000 (16:30 +0200)]
arm64: zynqmp: Fix User MTD partition size
The commit c8630167e0dc ("arm64: zynqmp: Add mtd partition for secure OS
storage area") didn't update User partition size that's why size was beyond
actual device size.
arm64: zynqmp: Fix issue of apps executing from R5 core 1
In current implementation, applications can execute only on R5 core 0.
The boot address for R5 core 1 is not supplied. Pass TCM address for
R5 core 1 based on the argument to fix the issue.
- Assorted bootstd fixes and cleanups. This should fix problems with
Debian, and make script-based distributions work when BOOTMETH_DISTRO
is enabled now (as BOOTMETH_DISTRO was renamed and then reintroduced).
Simon Glass [Wed, 10 May 2023 22:34:47 +0000 (16:34 -0600)]
bootstd: Create a new BOOTMETH_DISTRO
We cannot be sure what bootmeth a distro will need to use. Add a new
BOOTMETH_DISTRO option which collects these together. Select this from
BOOTSTD_DEFAULTS so that it is clear what is needed.
Signed-off-by: Simon Glass <sjg@chromium.org>
[trini: Make BOOTMETH_EFILOADER depend on EFI_LOADER, select if EFI_LOADER] Signed-off-by: Tom Rini <trini@konsulko.com>
Simon Glass [Wed, 10 May 2023 22:34:46 +0000 (16:34 -0600)]
bootstd: Rename distro and syslinux to extlinux
We use the terms 'distro' to mean extlinux but they are not really the
same. 'Distro' could refer to any method of booting a distribution,
whereas extlinux is a particular method.
Also we sometimes use syslinux, but it is better to use the same term in
all cases.
Rename distro to syslinux and also update bootstd uses of syslinux to use
extlinux instead.
Simon Glass [Wed, 10 May 2023 22:34:26 +0000 (16:34 -0600)]
bootstd: Tidy up reporting of errors
In a few cases the error handling is not quite right. Make sure we
return the actual error in distro_efi_read_bootflow_file() rather than
-EINVAL. Return -IO when a file cannot be read. Also show the error name
if available.
This does not change operation, but does make it easier to diagnose
problems.
Simon Glass [Sat, 6 May 2023 14:27:09 +0000 (08:27 -0600)]
bootstd: Correct default boot command
The patch to relax flag requirements was not accepted[1], so we still have
to have separate bootcommands depending on CMD_BOOTFLOW_FULL.
The previous attempt at this did not work, since it used the wrong name
for the options.
Fix this and change the message to mention BOOTSTD_FULL since this affects
not just the flags, but all functionality, so is more likely what the user
wants.
Drop the useless condition on CMD_BOOTFLOW_FULL while we are here.
Simon Glass [Fri, 28 Apr 2023 19:18:09 +0000 (13:18 -0600)]
bootstd: Work around missing partition 1
If there is no partition numbered 1, we decide that there are no
partitions at all. That may not be correct, since at least one Debian
installed has just a single partition numbered 2.
Continue searching up to partition 3, just in case.
* When called from efi_dp_from_name() we miss to append the filename
for non-block devices.
* expand_media_path() could be simplified by using efi_dp_from_file to
prepend the device path of the boot device.
This can be avoided by passing a device path to efi_dp_from_file() instead
of a block device descriptor and a partition number.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Ilias Apalodimas [Thu, 11 May 2023 16:40:35 +0000 (19:40 +0300)]
efi_loader: Fix warnings for unaligned accesses
Tom reports that when building with clang we see this warning:
field guid within 'struct efi_hii_keyboard_layout' is less aligned than 'efi_guid_t' and is usually due to 'struct efi_hii_keyboard_layout' being packed, which can lead to unaligned accesses [-Wunaligned-access]
This happens because 'struct efi_hii_keyboard_layout' is defined as
packed and thus has 1-byte alignment but efi_guid_t is a type that
requires greater alignment than that.
However the EFI spec describes the EFI_GUID as
"128-bit buffer containing a unique identifier value.
Unless otherwise specified"
So convert the efi_guid_t -> u8 b[16] here and skip the alignment
requirements. Since the struct is packed to begin with, it makes no
difference on the final memory layout.
Suggested-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reported-by: Tom Rini <trini@konsulko.com> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Symbol CONFIG_EFI_SETUP_EARLY does not exist anymore.
CONFIG_FWU_MULTI_BANK_UPDATE without CONFIG_FWU_MDATA results in
lib/fwu_updates/fwu.c:49: undefined reference to `fwu_get_mdata'
Fixes: 86794052418b ("FWU: Add support for the FWU Multi Bank Update feature") Fixes: 023d9c93932c ("efi_loader: remove CONFIG_EFI_SETUP_EARLY") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Acked-by: Sughosh Ganu <sughosh.ganu@linaro.org>
The config file (spkgimage.cfg in this example) contains additional
parameters such as NAND ECC settings.
Signed-off-by: Ralph Siemsen <ralph.siemsen@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Ralph Siemsen [Sat, 13 May 2023 01:36:51 +0000 (21:36 -0400)]
clk: renesas: add R906G032 driver
Clock driver for the Renesas RZ/N1 SoC family. This is based on
Linux kernel 6.2.y drivers/clk/renesas/r9a06g032-clocks.c as found in
commit 02693e11611e ("clk: renesas: r9a06g032: Repair grave increment error"),
with the following additional patch series applied:
https://lore.kernel.org/linux-renesas-soc/20230301215520.828455-1-ralph.siemsen@linaro.org/
Notable difference: this version avoids allocating a 'struct clk'
for each clock source, as this is problematic before relocation.
Instead, it uses the same approach as existing Renesas R-Car Gen2/3
clock drivers, using a temporary structure filled on-the-fly.
Signed-off-by: Ralph Siemsen <ralph.siemsen@linaro.org> Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Ralph Siemsen [Sat, 13 May 2023 01:36:50 +0000 (21:36 -0400)]
clk: renesas: prepare for non R-Car clock drivers
Add new CONFIG_CLK_RCAR to control compilation of shared code for R-Car
clock drivers (renesas-cpg-mssr.c). Enable this for R-Car Gen2 and 3.
This is necessary so that CONFIG_CLK_RENESAS can be enabled, allowing
recursion into the drivers/clk/reneasas directory, without bringing in
the R-Car support code. The support code contains platform specific
access (TMU_BASE) which is not needed on other Renesas devices such as
RZ/N1.
Signed-off-by: Ralph Siemsen <ralph.siemsen@linaro.org> Reviewed-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Ralph Siemsen [Sat, 13 May 2023 01:36:49 +0000 (21:36 -0400)]
ARM: armv7: add non-SPL enable for Cortex SMPEN
Commit 2564fce7eea3 ("sunxi: move Cortex SMPEN setting into start.S")
added SPL_ARMV7_SET_CORTEX_SMPEN to enable setting SMP bit. For
platforms not using SPL boot, add the corresponding non-SPL config,
so that CONFIG_IS_ENABLED(ARMV7_SET_CORTEX_SMPEN) works as expected.
Signed-off-by: Ralph Siemsen <ralph.siemsen@linaro.org> Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Simon Glass [Thu, 4 May 2023 22:50:59 +0000 (16:50 -0600)]
x86: Simplify cpu_jump_to_64bit_uboot()
This copies the cpu_call64() function to memory address and then jumps to
it. This seems to work correctly even when called from SPL, which is
running from SPI flash.
Drop the copy as it is not needed.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Thu, 4 May 2023 22:50:58 +0000 (16:50 -0600)]
spl: Commit MTRRs only in board_init_f_r()
We don't need to commit the SPI-flash MTRR change immediately, since it is
now done in the board_init_f_r(). Also this causes chromebook_link64 to
hang, presumably since we are still running from CAR (Cache-as-RAM) in
SPL. Coral handles this OK, perhaps since it is running from a different
memory area, but it has no effect on Coral anyway.
Drop the extra mtrr_commit() in the SPL implementation.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Thu, 4 May 2023 22:50:57 +0000 (16:50 -0600)]
x86: spl: Avoid using init_cache_f_r() from SPL
This function is used by U-Boot proper. It does not set up MTRRs when SPL
is enabled, but we do want this done when it is called from SPL. In fact
it is confusing to use the same function from SPL, since there are quite
a few conditions there.
All init_cache_f_r() really does is commit the MTRRs and set up the cache.
Do this in the SPL's version of this function instead.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Thu, 4 May 2023 22:50:55 +0000 (16:50 -0600)]
x86: Tidy up address for loading U-Boot from SPL
Use the binman symbols for this, to avoid hard-coding the value. We could
use CONFIG_X86_OFFSET_U_BOOT for the address, but it seems better to
obtain the offset and size through the same mechanism.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Tue, 9 May 2023 10:13:47 +0000 (18:13 +0800)]
x86: sysreset: Set up LPC only after relocation
Probing LPC can cause PCI enumeration to take place, which significantly
increases pre-relocation memory usage. Also, LPC is somtimes enabled
directly by SPL.
Adjust the logic to probe the LPC only after relocation. This allows
chromebook_link64 to start up without a much larger
CONFIG_SYS_MALLOC_F_LEN value.
Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Thu, 4 May 2023 22:50:52 +0000 (16:50 -0600)]
x86: Tidy up availability of string functions
For now, just enable the fast-but-large string functions in 32-boot
U-Boot proper only. Avoid using them in SPL. We cannot use then in 64-bit
builds since we only have 32-bit assembly.
Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Signed-off-by: Simon Glass <sjg@chromium.org>
Simon Glass [Thu, 4 May 2023 22:50:48 +0000 (16:50 -0600)]
sf: Rename spi-nor-tiny functions
The 'tiny' SPI nor functions have the same name as their big brothers,
which can be confusing. Use different names so it is clear which
version is in the image.
Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Thu, 4 May 2023 22:50:45 +0000 (16:50 -0600)]
dm: Emit the arch_cpu_init_dm() even only before relocation
The original function was only called once, before relocation. The new
one is called again after relocation. This was not the intent of the
original call. Fix this by renaming and updating the calling logic.
With this, chromebook_link64 makes it through SPL.
Fixes: 7fe32b3442f0 ("event: Convert arch_cpu_init_dm() to use events") Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Thu, 4 May 2023 22:55:01 +0000 (16:55 -0600)]
pci: coreboot: Don't read regions when booting
When U-Boot is the second-stage bootloader, PCI is already set up. We
cannot read the regions from the device tree. There is no point anyway,
since PCI devices have already been allocated according to the regions
and it is not safe for U-Boot to make any changes.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Fixes: f2ebaaa9f38d ("pci: Handle failed calloc in decode_regions()") Tested-by: Christian Gmeiner <christian.gmeiner@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Thu, 4 May 2023 22:55:00 +0000 (16:55 -0600)]
x86: Allow locating the UART from ACPI tables
When coreboot does not pass a UART in its sysinfo struct, there is no
easy way to find it out.
Since coreboot does not actually init the serial device when serial is
disabled, it is not possible to make it add this information to the
sysinfo table.
Add a way to obtain this information from the DBG2 ACPI table, which is
normally set up by coreboot.
For now this only supports a memory-mapped 16550-style UART.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Thu, 4 May 2023 22:54:59 +0000 (16:54 -0600)]
x86: coreboot: Collect the address of the ACPI tables
At present any ACPI tables created by prior-stage firmware are ignored.
It is useful to be able to view these in U-Boot.
Pick this up from the sysinfo tables and display it with the cbsysinfo
command. This allows the 'acpi list' command to work when booting from
coreboot.
Adjust the global_data condition so that acpi_start is available even if
table-generation is disabled.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Thu, 4 May 2023 22:54:57 +0000 (16:54 -0600)]
acpi: Create a new Kconfig for ACPI
We have several Kconfig options for ACPI, but all relate to specific
functions, such as generating tables and AML code.
Add a new option which controls including basic ACPI library code,
including the lib/acpi directory. This will allow us to add functions
which are available even if table generation is not supported.
Adjust the command to avoid a build error when ACPIGEN is not enabled.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Thu, 4 May 2023 22:54:56 +0000 (16:54 -0600)]
input: Flush the keyboard buffer before resetting it
If U-Boot is not the first-stage bootloader the keyboard may already be
set up. Make sure to flush any data before trying to reset it. This
avoids a long timeout / hang.
Add some comments and a log category while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Thu, 4 May 2023 22:54:55 +0000 (16:54 -0600)]
x86: Adjust search range for sysinfo table
Avoid searching starting at 0 since this memory may not be available,
e.g. if protection against NULL-pointer access is enabled. The table
cannot be there anyway, since the first 1KB of memory was originally
used for the interrupt table and coreboot avoids it.
Start at 0x400 instead.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tom Rini [Tue, 9 May 2023 16:45:49 +0000 (12:45 -0400)]
Merge tag 'u-boot-rockchip-20230509' of https://source.denx.de/u-boot/custodians/u-boot-rockchip
- Rockchip NFC driver update and dev addr pointer api update;
- use standard dr_mode for usb driver;
- rock pi boards dts update;
- Add rk3566 Anbernic boards;
- Misc fixes for drivers;
The CRU is being probed with a default set of assigned clocks, which
are not implemented in the driver at all.
Hence, when clk_set_defaults is called, it fails with ENOENT.
This would not be a problem, as the CRU still handles all the required
clocks, and the assigned clocks are default configs which are preprogrammed
or not required for Uboot operations.
However, the rockchip reset driver is being bound by the same DT node
as CRU, as the reset driver has no DT node.
But, when probing the reset node, it will call again the clk_set_defaults
for the CRU node, and failing because of missing those specific clocks
in the rk3588 clock driver.
To avoid this, simply implement a basic set/get that will just return
success and the default corresponding rate for the required assigned clocks.
As those clocks were not supported in Uboot, not required for Uboot
operations, there is no need to do any different kind of initialization.
Signed-off-by: Eugen Hristev <eugen.hristev@collabora.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
John Keeping [Wed, 12 Apr 2023 11:52:53 +0000 (12:52 +0100)]
rockchip: handle peripheral as well as otg dr_mode
The OTG port is identified by inspecting the "dr_mode" property which is
expected to be "otg" for this port. But it will work just as well as a
device controller when dr_mode is set to "peripheral", which may be
required if the mode detection pin is not set up correctly and the
device controller needs to be programmed to override this.
Signed-off-by: John Keeping <john@metanate.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
projects / u-boot.git / log