Migrate PX30/RK3326 boards that exists in Linux v6.8 to use OF_UPSTREAM.
firefly-px30 is not migrated to OF_UPSTREAM because there's no Device
Tree in the Linux kernel.
Differences between U-Boot's Odroid-Go2 and Linux's are now moved to the
-u-boot.dtsi, though I have a gut feeling that the existing cru
overrides aren't necessary (anymore?).
The U-Boot GPIO led-0 is on GPIO0_C1 but such is the pin of PWM3 which
is used for Linux's PWM led-2 so keep Linux's.
I also doubt vcc_cam is actually used, though the Odroid-Go2 Black
Edition uses this dcdc regulator for WiFi, so let's just move it to the
-u-boot.dtsi to play it safe.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
In the Device Tree, UART5 is the system UART, but in the defconfig it
currently is UART2. Let's sync the two by making the defconfig use UART5
as well.
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
In order to be able to properly mux UART on PX30 EVB, the pinmux needs
to be done at runtime, so let's not remove the pinctrl nodes from the
SPL DTB.
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
This adds the default pinmux for UART2 and UART5 to the TPL/SPL DTB (if
not removed through the CONFIG_OF_SPL_REMOVE_PROPS symbol) as those two
controllers are always made available to all boards.
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
U-Boot proper pre-reloc is currently running out of memory on PX30
Ringneck and it is thus impossible to boot into U-Boot CLI. It is
assumed the same problem can be seen on other PX30 boards though I
cannot guarantee it since I don't have access to them.
Fix this by migrating to the common bss and stack addresses for PX30,
which drastically increases the size of the pre-reloc allocation pool (8
times bigger now). The memory layout in SPL and U-Boot proper now
match the other SoCs' using ROCKCHIP_COMMON_STACK_ADDR.
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
U-Boot proper pre-reloc is currently running out of memory on PX30
Ringneck and it is thus impossible to boot into U-Boot CLI. It is
assumed the same problem can be seen on other PX30 boards though I
cannot guarantee it since I don't have access to them.
Fix this by migrating to the common bss and stack addresses for PX30,
which drastically increases the size of the pre-reloc allocation pool (8
times bigger now). The memory layout in SPL and U-Boot proper now
match the other SoCs' using ROCKCHIP_COMMON_STACK_ADDR.
Tested-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
U-Boot proper pre-reloc is currently running out of memory on PX30
Ringneck and it is thus impossible to boot into U-Boot CLI. It is
assumed the same problem can be seen on other PX30 boards though I
cannot guarantee it since I don't have access to them.
Fix this by migrating to the common bss and stack addresses for PX30,
which drastically increases the size of the pre-reloc allocation pool (8
times bigger now). The memory layout in SPL and U-Boot proper now
match the other SoCs' using ROCKCHIP_COMMON_STACK_ADDR.
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
U-Boot proper pre-reloc is currently running out of memory on PX30
Ringneck and it is thus impossible to boot into U-Boot CLI. It is
assumed the same problem can be seen on other PX30 boards though I
cannot guarantee it since I don't have access to them.
Fix this by migrating to the common bss and stack addresses for PX30,
which drastically increases the size of the pre-reloc allocation pool (8
times bigger now). The memory layout in SPL and U-Boot proper now
match the other SoCs' using ROCKCHIP_COMMON_STACK_ADDR.
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
There are two paths to reach this function, either through mkimage -l or
through dumpimage -l. The latter passes a NULL imagename while the
former passes an empty string. Therefore, let's make both tools behave
the same by handling the empty string the same way as for NULL.
Without this, the only way to get some information out of mkimage -l is
to provide "-n rk3399" for example, which isn't documented in the usage
of the tool.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
GPIO IOMUX control is located at PMU2_IOC or BUS_IOC offset on RK3588.
Based on Linux commit fdc33eba11c5 ("pinctrl/rockchip: add rk3588
support").
Compared to the Linux commit, this include a fix so that the iomux of
GPIO0_B4-D7 is reported correctly.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
GPIO0_C0-C4 iomux is set using PMUGRF_GPIO0C_IOMUX_L reg on RV1126. This
is indicated using the IOMUX_L_SOURCE_PMU flag. Fix reading current mux
by fully adopting the IOMUX_L_SOURCE_PMU related code in Linux kernel.
Based on Linux commit fd4ea48688c6 ("pinctrl: rockchip: Add RV1126
pinctrl support").
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
GPIO0_A0-A7 on RK3188 is IOMUX_GPIO_ONLY, however, trying to set gpio
mux return an -ENOTSUPP error code. Fix this by validating using the mux
function type and not the iomux flag.
Based on Linux commit c4a532dee6b6 ("pinctrl: rockchip: handle first
half of rk3188-bank0 correctly").
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
My linter complains that the order isn't clear enough so let's put
parentheses around the ternary condition to make it happy.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org> # chromebook-bob
For the sake of consistency, make all internal (starting with _)
functions expect a pmic udevice instead of a regulator udevice.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org> # chromebook-bob
_ldo_get_suspend_value and _ldo_set_suspend_value get passed the parent
of the regulator (so the pmic) as first argument, therefore this udevice
should be used for pmic_* callbacks instead of using the parent of the
pmic.
To avoid further confusion, let's rename the argument to pmic instead of
dev, highlighting which kind of device we expect as argument.
Fixes: f047e4ab9762 ("regulator: rk8xx: add indirection level for some ldo callbacks")
Reported-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org> # chromebook-bob
Some of the rgxx3 devices do not have a way to recover from a poor
flash of a bootloader to eMMC. Set the device to always attempt to boot
from sdmmc0 first which ensures that we can override the boot from
emmc if we have a card present with a valid fit signature. The
expectation is that this will protect from the very unlikely chance
we have a valid FIT signature on the eMMC but the U-Boot stage fails
for some other reason.
Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
This reverts commit 41a60d0e5cef54a59596a58940fa7c9cf071034b.
On some of the supported devices the adc detect code always returns
that the button has been pushed, and as a result the device will
not boot normally.
Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Add tests for booting image using tftpboot/pxe boot commands, tftpboot
boot case loads the FIT image into DDR and boots using bootm command
whereas pxe boot cases downloads the pxe configuration file from the
TFTP server and interprets it to boot the images mentioned in the pxe
configurations file.
This test relies on boardenv_* containing configuration values including
the parameter 'pattern'. tftpboot/pxe boot cases boots the Linux till the
boot log pattern value is matched. For example, if the parameter
'pattern' is defined as 'login:', it will boot till login prompt.
Signed-off-by: Love Kumar <love.kumar@amd.com>
Tested-by: Tom Rini <trini@konsulko.com>
Executing a u-boot command may raise an error or extra bad pattern,
beyond the default bad patterns. Providing a way to enable the console
output error check in test.
For example, description for OS boot test:
import re
check_type = 'kernel_boot_error'
check_pattern = re.compile('ERROR -2: can't get kernel image!')
with u_boot_console.enable_check(check_type, check_pattern):
u_boot_console.run_command('<boot command>')
Signed-off-by: Love Kumar <love.kumar@amd.com>
commit dfeb4f0d7935 ("cmd: bcb: extend BCB C API to allow read/write the fields")
introduced the bcb_get() function.
When CONFIG_CMD_BCB=n, that function is stubbed.
The stubbed function has a wrong prototype: value_size arg is missing.
Add the missing argument to fix build when CONFIG_CMD_BCB=n.
Fixes: dfeb4f0d7935 ("cmd: bcb: extend BCB C API to allow read/write the fields")
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Reviewed-by: Guillaume La Roque <glaroque@baylibre.com>
Reviewed-by: Dmitrii Merkurev <dimorinny@google.com>
Reviewed-by: Julien Masson <jmasson@baylibre.com>
Allow extraction of zstd-compressed images from FIT using imxtract
command. This is especially useful when one has to load an image via
some interface (e.g. SPI) rather that just to the memory.
Signed-off-by: Dmitry Gerasimov <di.gerasimov@gmail.com>
When bcmgenet complete to write Rx buffer with the DMA,
some U-Boot commands write data to the buffer directly.
Those write data will become dirty in CPU cache.
After this driver calls free_pkt to the buffer,
the buffer is assigned as the future Rx buffer.
At some point, if bcmgenet writes to a buffer with DMA
and CPU cache flushes dirty data to the buffer,
the buffer is corrupted.
This patch calls flush_dcache_range in free_pkt
to immediately flush the data written by U-Boot command
and prevent data corruption.
This issue can be reproduced using wget on Raspberry Pi4.
If wget receives data larger than
RX_BUF_LENGTH * RX_DESCS = 2048 * 256 bytes,
it will timeout due to data corruption.
In addition, if LOG_DEBUG is enabled in net/tcp.c,
the following error log is output.
TCP RX TCP xSum Error
Signed-off-by: Yasuharu Shibata <yasuharu.shibata@gmail.com>
All ARCH_K3 platforms need about of 2MB of malloc space post
reallocation. Since, this space is allocated from SDRAM, provide a
generous 2MB space by default.
Platforms requiring more than 2MB can override in defconfig as needed.
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
The default DM firmware path is non-optional as of now. Make it
optional so that users that choose to provide DM via TI_DM argument
instead of BINMAN_INDIRS can do so without build errors.
Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
Reviewed-by: Kamlesh Gurudasani <kamlesh@ti.com>
According to [0], raw access to mmc should not have mmcpart in the
entry. This was fixed in k3_dfu_combined.env but k3_dfu.env had been
overlooked.
[0] doc/usage/dfu.rst
Fixes: 53b406369e9d ("DFU: Check the number of arguments and argument string strictly")
Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
MAIN_PLL0 has a flag set in DM (Device Manager) that removes its
capability to re-initialise clock frequencies. A72 CPU clock (GTC) and
RGMII has MAIN_PLL3 as their parent which does not have this flag. While
RGMII needs re-initialization to default frequency to be able to get
250MHz with its divider, GTC can not get its required 200MHz with its
dividers. Thus move GTC clock parent on J721S2 from MAIN_PLL3_HSDIV1 to
MAIN_PLL0_HSDIV6. This was already done on CPTS node in kernel which was
similarly affected (linked).
Link: https://lore.kernel.org/all/20230605110443.84568-1-n-francis@ti.com/
Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
Switch PHY_ANEG_TIMEOUT to CONFIG_PHY_ANEG_TIMEOUT Kconfig symbol.
This removes one more configuration headers option finalizes its
Kconfig symbol conversion. No functional change expected.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Let users configure default auto-negotiation timeout via Kconfig
instead of specifying it in board configuration headers. This is
the first step toward converting this to Kconfig fully, so far the
legacy PHY_ANEG_TIMEOUT in configuration headers takes precedence.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
There's never been a -q or -s argument handled in the command, so let's
remove it. This was highlighted during review[1] but somehow still got
through.
While at it, slightly "reword" in the help text how the len + freq
arguments are defined. Indeed, len and freq work in pair, it is possible
to define none of either, n of both, or n - 1 of freq if there are n
len, in which case the freq that goes with the last len would be the n -
1 (and not the default of 400Hz if neither len nor freq is passed). I
assume this isn't what's expected but leaving it for another patch if
need be to fix what happens in that very odd scenario.
[1] https://lore.kernel.org/u-boot/CAPnjgZ0QWNqVFZfEWHxRcFOA3E3gRAZCYs77nGUXKL0pLp+JLQ@mail.gmail.com/
Fixes: ea58b9a404d4 ("cmd: allow sound command to play multiple sounds")
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
R5 being a 32-bit processor can't understand the 64-bit mapping being
done in ospi node. Override the ospi node for 32-bit register ranges and
the fss node ( the parent node of ospi ) to map the ranges for the
updated child node correctly.
Reviewed-by: Apurva Nandan <a-nandan@ti.com>
Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>
On DTR capable flashes like Micron Xcella the writes cannot start or end
at an odd address in DTR mode. Extra 0xff bytes need to be prepended or
appended respectively to make sure both the start and end addresses are
even.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Signed-off-by: Apurva Nandan <a-nandan@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Tested-by: Jonathan Humphreys <j-humphreys@ti.com>
Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>
UEFI:
* Allow specifying a device-tree in an EFI load option
using the efidebug or eficonfig command.
* Let the EFI boot manager fall back to an OS provided device-tree
if no device-tree is specified.
-----BEGIN PGP SIGNATURE-----
iQJWBAABCABAFiEEK7wKXt3/btL6/yA+hO4vgnE3U0sFAmZoOXUiHGhlaW5yaWNo
LnNjaHVjaGFyZHRAY2Fub25pY2FsLmNvbQAKCRCE7i+CcTdTS36HEACegzro+P2f
XZbdiRi0zN+ef5UkUVm/LECwBWXo0p9R5L3XWsRtxz8nqzG5JgB4lzDr0X3cRAVr
uUeg6xf5LSXCbme/Ct68bi27F54Z0OQDmVlvPC/zUQ6CUDPg+0HFlHiBgKGvkAy+
0HZY57OhXbviyuZ8JND/zL5GBGnyVGjyoghS0OvtSeWZ+6JIHYrMGH9fc1jtdS4+
jleIkKE4NKIJPOPQVpCr84SgtbsfFeaOtsAM6u5Asd8FkmKLjcgNpKw5Kj03vJwP
javMY/hG7LkAxHLEfDOe1A3z8AKqN+zrHZ0Rj7Xy+TdwEmh6IgsPkorPCjWa5g0W
Cp7pjf2Bq/dAZLhHCMPFBQ/aSv9t3b+LSdrGYJUffwmjhcJ/6+J+2ioD50cJc31E
Ov85HF7FpB9s82+3LL9QuFkQIdDdseNPCPUdEesA1GJjZUa8QrrrmmeTDuZZAmXm
HpAy3/hw1lTYG/yPSavQdr0bZNTcersvpIqchI5b/SXfAH+riSSuGGobtaYE61su
2esMKTMma1/aO2X3i7QCTntG4fKd/7Wfbf3lcjIJ3nuWlty+AvXZiD1nHM48d2P4
U3/Wbsls60mlAG/P15/eC8jxhkanrbSXNwGOjJMbh+OmwUukhvYg+35t5qZkCwuW
OHIFOWhFuIs+tsEUoOllZldDgmWB9hpjxg==
=D5PO
-----END PGP SIGNATURE-----
Merge tag 'efi-next-20240611' of https://source.denx.de/u-boot/custodians/u-boot-efi into next
Pull request efi-next-20240611
UEFI:
* Allow specifying a device-tree in an EFI load option
using the efidebug or eficonfig command.
* Let the EFI boot manager fall back to an OS provided device-tree
if no device-tree is specified.
The issue described in https://github.com/psf/requests/pull/6655 has
been assigned as a security issue. While unlikely to be exploited in our
usage, update to the current release to fix it. Furthermore, upstream
has now moved on to v2.23.2 as the release to use which has all of the
issues resolved.
Reported-by: GitHub dependabot
Signed-off-by: Tom Rini <trini@konsulko.com>
Comment is not kernel-doc format that's why don't label it like that and
also fix indentation to have proper multiline comment.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Fix a trivial typo in the bootmeth documentation.
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
According to UEFI v2.10 spec section 8.2.6, if a caller invokes the
SetVariables() service, it will produce a digest from hash(VariableName,
VendorGuid, Attributes, TimeStamp, DataNew_variable_content), then the
firmware that implements the SetVariable() service will compare the
digest with the result of applying the signer’s public key to the
signature. For EFI variable append write, efitools sign-efi-sig-list has
an option "-a" to add EFI_VARIABLE_APPEND_WRITE attr, and u-boot will
drop this attribute in efi_set_variable_int(). So if a caller uses
"sign-efi-sig-list -a" to create the authenticated variable, this append
write will fail in the u-boot due to "hash check failed".
This patch resumes writing the EFI_VARIABLE_APPEND_WRITE attr to ensure
that the hash check is correct. And also update the "test_efi_secboot"
test case to compliance with the change.
Signed-off-by: Weizhao Ouyang <o451686892@gmail.com>
As we now also store device-tree device-paths in load options rename
struct efi_initrd_dp to efi_lo_dp_prefix.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
If no device-tree is specified, try to load a device-tree from the boot
device use the $fdtfile concatenated to either of the paths '/dtb/', '/',
'/dtb/current/'.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
We can reuse this function to load the device-tree.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
For finding distro supplied device-trees we need to know from which device
we are booting. This can be identified via the device-path of the binary.
Up to now efi_dp_from_lo() only could return the initrd or fdt device-path.
Allow returning the binary device-path, too.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Move distro_efi_get_fdt_name() to a separate C module
and rename it to efi_get_distro_fdt_name().
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
We allow to specify the triple of binary, initrd, and device-tree in boot
options.
Add the code to actually load the specified device-tree.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
