| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Mattijs Korpershoek <mkorpershoek@baylibre.com> says:
Android boot flow is a bit different than a regular Linux distro.
Android relies on multiple partitions in order to boot.
A typical boot flow would be:
1. Parse the Bootloader Control Block (BCB, misc partition)
2. If BCB requested bootonce-bootloader, start fastboot and wait.
3. If BCB requested recovery or normal android, run the following:
a. Get slot (A/B) from BCB
b. Run AVB (Android Verified Boot) on boot partitions
c. Load boot and vendor_boot partitions
d. Load device-tree, ramdisk and boot
The AOSP documentation has more details at [1], [2], [3]
This has been implemented via complex boot scripts such as [4].
However, these boot script are neither very maintainable nor generic.
Moreover, DISTRO_DEFAULTS is being deprecated [5].
Add a generic Android bootflow implementation for bootstd.
For this initial version, only boot image v4 is supported.
This has been tested on sandbox using:
$ ./test/py/test.py --bd sandbox --build -k test_ut
This has also been tested on the AM62X SK EVM using TI's Android SDK[6]
To test on TI board, the following (WIP) patch is needed as well:
https://gitlab.baylibre.com/baylibre/ti/ti-u-boot/-/commit/84cceb912bccd7cdd7f9dd69bca0e5d987a1fd04
[1] https://source.android.com/docs/core/architecture/bootloader
[2] https://source.android.com/docs/core/architecture/partitions
[3] https://source.android.com/docs/core/architecture/partitions/generic-boot
[4] https://source.denx.de/u-boot/u-boot/-/blob/master/include/configs/meson64_android.h
[5] https://lore.kernel.org/r/all/20230914165615.1058529-17-sjg@chromium.org/
[6] https://software-dl.ti.com/processor-sdk-android/esd/AM62X/09_02_00/docs/android/Overview.html
|
|
Rasmus Villemoes <rasmus.villemoes@prevas.dk> says:
This is a followup to the patches that landed in 2024.01 and nearly
made sure that source files for producing .dtbo files use the .dtso
extension. In the same release, a few new .dts files snuck in, and
there was also some test code involving .dtbo -> .dtbo.S -> .dtbo.o I
didn't really know how to handle at the time. This should finish the
job, bring us in sync with linux (at least in this respect), and drop
the .dts -> .dtbo build rule.
|
|
Add a unit test for testing the Android bootmethod.
This requires another mmc image (mmc7) to contain the following partitions:
- misc: contains the Bootloader Control Block (BCB)
- boot_a: contains a fake generic kernel image
- vendor_boot_a: contains a fake vendor_boot image
Also add BOOTMETH_ANDROID as a dependency on sandbox so that we can test
this with:
$ ./test/py/test.py --bd sandbox --build -k test_ut # build the mmc7.img
$ ./test/py/test.py --bd sandbox --build -k bootflow_android
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Reviewed-by: Julien Masson <jmasson@baylibre.com>
Reviewed-by: Guillaume La Roque <glaroque@baylibre.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
Android boot flow is a bit different than a regular Linux distro.
Android relies on multiple partitions in order to boot.
A typical boot flow would be:
1. Parse the Bootloader Control Block (BCB, misc partition)
2. If BCB requested bootonce-bootloader, start fastboot and wait.
3. If BCB requested recovery or normal android, run the following:
3.a. Get slot (A/B) from BCB
3.b. Run AVB (Android Verified Boot) on boot partitions
3.c. Load boot and vendor_boot partitions
3.d. Load device-tree, ramdisk and boot
The AOSP documentation has more details at [1], [2], [3]
This has been implemented via complex boot scripts such as [4].
However, these boot script are neither very maintainable nor generic.
Moreover, DISTRO_DEFAULTS is being deprecated [5].
Add a generic Android bootflow implementation for bootstd.
For this initial version, only boot image v4 is supported.
[1] https://source.android.com/docs/core/architecture/bootloader
[2] https://source.android.com/docs/core/architecture/partitions
[3] https://source.android.com/docs/core/architecture/partitions/generic-boot
[4] https://source.denx.de/u-boot/u-boot/-/blob/master/include/configs/meson64_android.h
[5] https://lore.kernel.org/r/all/20230914165615.1058529-17-sjg@chromium.org/
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Julien Masson <jmasson@baylibre.com>
Tested-by: Guillaume La Roque <glaroque@baylibre.com>
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
|
|
The only way to configure the load addresses for both bootimg and
vendor_bootimg is by using the "abootimg" command.
If we want to use the C API, there is no equivalent.
Add set_abootimg_addr() and set_avendor_bootimg_addr() so that we can
specify the load address from C.
This can be useful for implementing an Android bootmethod.
Reviewed-by: Igor Opaniuk <igor.opaniuk@gmail.com>
Reviewed-by: Julien Masson <jmasson@baylibre.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Guillaume La Roque <glaroque@baylibre.com>
Tested-by: Guillaume La Roque <glaroque@baylibre.com>
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
|
|
Some bootflows might be able to only boot from MMC devices.
Add a helper function these bootflows can use.
Reviewed-by: Igor Opaniuk <igor.opaniuk@gmail.com>
Reviewed-by: Julien Masson <jmasson@baylibre.com>
Reviewed-by: Guillaume La Roque <glaroque@baylibre.com>
Tested-by: Guillaume La Roque <glaroque@baylibre.com>
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
When calling android_image_get_dtb_by_index() using boot image v3+,
we should also pass the vendor_boot ramdisk address.
Use get_avendor_bootimg_addr() to do so.
Notes: on boot image v2, this is harmless since get_avendor_bootimg_addr()
returns -1.
for legacy implementations that don't have CMD_ABOOTIMG, add a weak
implementation to avoid linking errors.
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Julien Masson <jmasson@baylibre.com>
Reviewed-by: Igor Opaniuk <igor.opaniuk@gmail.com>
Reviewed-by: Guillaume La Roque <glaroque@baylibre.com>
Tested-by: Guillaume La Roque <glaroque@baylibre.com>
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
|
|
[equivalent to linux commit 81d362732bac]
As a follow up to the series allowing DTB overlays to built from .dtso
files. Now that all overlays have been renamed, remove the ability to
build from overlays from .dts files to prevent any files with the old
name from accidental being added.
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
|
|
Distinguish more clearly between source files meant for producing .dtb
from those meant for producing .dtbo.
Note that in the linux tree, all device tree overlay sources have been
renamed to .dtso, and the .dts->.dtbo rule is gone since v6.5 (commit
81d362732bac). So this is also a step towards staying closer to linux
with respect to both Kbuild and device tree sources, and eventually
eliminating all .dts -> .dtbo instances.
This also matches the documentation update done in commit 4fb7e570d6b.
Cc: Masahisa Kojima <kojima.masahisa@socionext.com>
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
|
|
Distinguish more clearly between source files meant for producing .dtb
from those meant for producing .dtbo.
In this case, the files are really meant to be compiled to .dtbo ->
.dtbo.S -> .dtbo.o that get embedded in the image, which means that
the begin/end symbols generated by the makefile rule changes to
__dtbo_ rather than __dtb, so the consuming .c file needs updating,
but this should not result in any functional change.
Note that in the linux tree, all device tree overlay sources have been
renamed to .dtso, and the .dts->.dtbo rule is gone since v6.5 (commit
81d362732bac). So this is also a step towards staying closer to linux
with respect to both Kbuild and device tree sources.
Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: Simon Glass <sjg@chromium.org>
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
|
|
[linux commit 941214a512d8, modified for U-Boot by removing the
include of vmlinux.lds.h and replacing STRUCT_ALIGNMENT by 16.]
DTB files can be built into the kernel by converting them to assembly
files then assembling them into object files. We extend this here
for DTB overlays with the .dtso extensions.
We change the start and end delimiting tag prefix to make it clear that
this data came from overlay files.
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
|
|
Distinguish more clearly between source files meant for producing .dtb
from those meant for producing .dtbo. No functional change, as we
currently have rules for producing a foo.dtbo from either foo.dts or
foo.dtso.
Note that in the linux tree, all device tree overlay sources have been
renamed to .dtso, and the .dts->.dtbo rule is gone since v6.5 (commit
81d362732bac). So this is also a step towards staying closer to linux
with respect to both Kbuild and device tree sources.
Cc: Marek Vasut <marex@denx.de>
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Marek Vasut <marex@denx.de>
|
|
Remove the leftover Amlogic GX/G12 bindings headers that
maked the v6.10 upstream DT fail to build.
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
|
|
https://source.denx.de/u-boot/custodians/u-boot-rockchip
- Add boards:
rk3328: Radxa ROCK Pi E v3;
rk3588s: FriendlyElec NanoPi R6C/S;
- Remove board: Theobroma Systems RK3368 Lion;
- Add rk3588 pcie support;
- Misc updates for board and config;
CI: https://source.denx.de/u-boot/custodians/u-boot-rockchip/-/pipelines/2163
|
|
According to recently firmware handsoff spec [1]'s "Register usage at handoff
boundary", Transfer List's signature value was changed from 0x40_b10b
(3 bytes) to 4a0f_b10b (4 bytes).
As updating of TL's signature, register value of x1/r1 should be:
In aarch32's r1 value should be
R1[23:0]: set to the TL signature (4a0f_b10b -> masked range value: 0f_b10b)
R1[31:24]: version of the register convention == 1
and
In aarch64's x1 value should be
X1[31:0]: set to the TL signature (4a0f_b10b)
X1[39:32]: version of the register convention == 1
X1[63:40]: MBZ
(See the [2] and [3]).
This patch fix problems:
1. breaking X1 value with updated specification in aarch64
- change of length of signature field.
2. previous error value set in R1 in arm32.
- length of signature should be 24, but it uses 32bit signature.
This patch is a breaking change. It works only TF-A is updated.
Link: https://github.com/FirmwareHandoff/firmware_handoff [1]
Link: https://github.com/FirmwareHandoff/firmware_handoff/issues/32 [2]
Link: https://github.com/FirmwareHandoff/firmware_handoff/commit/5aa7aa1d3a1db75213e458d392b751f0707de027 [3]
Signed-off-by: Levi Yun <yeoreum.yun@arm.com>
Reviewed-by: Raymond Mao <raymond.mao@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
A security issue exists with zipp before v3.19.1, and the current
release is now v3.19.2. While the change in versions numbers is large, a
manual inspection of the changelog shows that it's not as big as might
be implied.
Reported-by: GitHub dependabot
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
As described in the document SMC Calling Convention (ARM DEN 0028 1.5 F),
section 7 "Arm Architecture Calls", the SMC call SMCCC_ARCH_FEATURES is
not expected to support the function ID ARM_SMCCC_TRNG_VERSION. Trusted
Firmware-A follows up the specification in its implementation.
This commit removes the invocation to avoid the failure - which is a
wrong calling in U-boot. The later code invokes ARM_SMCCC_TRNG_VERSION
for retrieving the TRNG version, except it can read back the version
number, it also can be used to detect whether the TRNG is supported or
not.
Signed-off-by: Leo Yan <leo.yan@arm.com>
Reviewed-by: Weizhao Ouyang <o451686892@gmail.com>
|
|
Instead of cluttering up a header file with a bunch of defines,
move the default environmental variables to a file called
am3517evm.env and reference it from the defconfig. Also
remove dead comments.
Signed-off-by: Adam Ford <aford173@gmail.com>
|
|
Skip setting parent with dummy fixed-clock. Upstream linux might declare
an additional clock for the mtk timer and that additional clock might
also be a fixed-clock defined in DT. Setting parent of a dummy fixed-clock
resulta in error hence mtk timer fails to probe.
Skip setting parent to permit correct probe of the mtk timer.
Fixes: d3c3606c5cc6 ("timer: MediaTek: add timer driver for MediaTek SoCs")
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
|
|
Vincent Stehlé <vincent.stehle@arm.com> says:
Hi,
This is a respin of this patch [1] after discussion [2]. Thanks to
Simon and Heinrich for their reviews.
To use the guidcmp() function, as suggested by Heinrich, we need to
make it available to bootmeth_cros.c and I think that the cleanest way
to do that is (arguably) to move the guid helper functions to efi.h
near the efi_guid_t definition; this is why the original patch has now
become a series of two patches.
The alternative would be to include efi_loader.h from bootmeth_cros.c
but I think this does not sound "right". If this is in fact the
preferred approach just let me know and I will respin.
There is no difference in the sandbox binaries before/after this
series on Arm and on PC, and all the tests I have run on the sandbox
are unchanged.
|
|
Enable USB host as well as USB gadget and DFU support for a53 and r5
configs. Also, enable UUU fastboot support to download files with
the UUU tool from a53.
Additionally, configure usb0 to peripheral mode and add extra
environment for DFU use.
Signed-off-by: Vitor Soares <vitor.soares@toradex.com>
Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
|
|
for rk3308, all defconfigs have CONFIG_OF_LIBFDT_OVERLAY=y, so enable it
by default.
for rk3328, any defconfig doesn't have it. but there is no strong reason
not to enable it. at least it's required for ROCK Pi E.
Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
|
- add support for compressed kernel for rk3308
- prepare support for fdtoverlay for rk3328
tested on ROCK Pi S 256MB, ROCK Pi E 2GB, and ROCK Pi 4A 4GB with
linux-next-20240613 defconfig kernel.
Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
|
this is cosmetic change. no functional change is intended.
- remove redundant white spaces
- replace white spaces with tab
- align position of last letter/word
- sort lines in CFG_EXTRA_ENV_SETTINGS
- add comment after #endif
Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
|
The pcie1ln_sel bits for the RK3588 are getting set but not cleared due
to an incorrect write mask.
Use a newly introduced constant for the write mask to fix this.
Also introduce a GENMASK-based constant for PCIE30_PHY_MODE.
This fix is adapted from the upstream Linux commit by Sebastian Reichel:
55491a5fa163 ("phy: rockchip-snps-pcie3: fix clearing PHP_GRF_PCIESEL_CON bits")
Fixes: 50e54e80679b ("phy: rockchip: snps-pcie3: Add support for RK3588")
Signed-off-by: Sebastian Kropatsch <seb-dev@mail.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
|
Misconfigured `PHP_GRF_PCIESEL` values are causing bifurcation issues,
for example on the FriendlyElec CM3588 NAS board which uses bifurcation
on both PCIe PCIe ports (all four lanes) to enable four M.2 NVMe
sockets. Without this fix, NVMe devices do not get recognized.
Correct the `PHP_GRF_PCIESEL` register configuration and simplify the
bifurcation logic, enabling proper PCIe bifurcation based on the
data-lanes property.
This fix is adapted from the upstream Linux commit by Michal Tomek:
f8020dfb311d ("phy: rockchip-snps-pcie3: fix bifurcation on rk3588")
Fixes: 50e54e80679b ("phy: rockchip: snps-pcie3: Add support for RK3588")
Signed-off-by: Sebastian Kropatsch <seb-dev@mail.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
|
Several identifiers use "rochchip" instead of "rockchip".
Fix this by replacing every instance of "rochchip" with "rockchip".
Signed-off-by: Sebastian Kropatsch <seb-dev@mail.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
|
Replace "rochchip" by "rockchip" in two instances.
Signed-off-by: Sebastian Kropatsch <seb-dev@mail.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
|
The NanoPi R6S is a SBC by FriendlyElec based on the Rockchip RK3588s.
It comes with 4GB or 8GB of RAM, a microSD card slot, 32GB eMMC storage,
one RTL8211F 1GbE and two RTL8125 2.5GbE Ethernet ports, one USB 2.0
Type-A and one USB 3.0 Type-A port, a HDMI port, a 12-pin GPIO FPC
connector, a fan connector, IR receiver as well as some buttons and LEDs.
Add initial support for this board using the upstream devicetree sources.
Kernel commit:
f1b11f43b3e9 ("arm64: dts: rockchip: Add support for NanoPi R6S")
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Signed-off-by: Sebastian Kropatsch <seb-dev@mail.de>
|
|
The NanoPi R6C is a SBC by FriendlyElec based on the Rockchip RK3588s.
It comes with 4GB or 8GB of RAM, a microSD card slot, optional 32GB eMMC
storage, one M.2 M-Key connector, one RTL8211F 1GbE and one RTL8125
2.5GbE Ethernet port, one USB 2.0 Type-A and one USB 3.0 Type-A port, a
HDMI port, a 30-pin GPIO header as well as multiple buttons and LEDs.
Add initial support for this board using the upstream devicetree sources.
Tested in U-Boot proper:
- Booting from eMMC works
- 1GbE Ethernet works using the eth_eqos driver (tested by ping)
- 2.5GbE Ethernet works using the eth_rtl8169 driver (tested by ping),
but the status LEDs on this specific port currently aren't working
- NVMe SSD in M.2 socket does get recognized (tested with `nvme scan`
followed by `nvme details`)
Kernel commit:
d5f1d7437451 ("arm64: dts: rockchip: Add support for NanoPi R6C")
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Signed-off-by: Sebastian Kropatsch <seb-dev@mail.de>
|
|
This enables PCIe support on Tiger as exposed on
Q7_PCIE[0123]_[RT]X_[PN] signals and more specifically on the `PCI
Express` connector on the Haikou devkit.
This was tested with a PCIe to NVMe adapter (e.g.
https://www.amazon.de/dp/B07RZZ3TJG).
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
|
Jaguar has an M.2 M-KEY slot for NVMes, connected to the PCIe3 4-lane
PHY on RK3588.
CONFIG_PHY_ROCKCHIP_NANENG_COMBOPHY=y is technically not necessary since
it's required only for the M.2 E-KEY slot on the main PCB, but that is
used typically for WiFi+BT modules, or on the mezzanine connector but
the features exposed behind that connector aren't supported in U-Boot
(no DT for it right now). However, if the PHY driver is missing, we get
the following error message:
pcie_dw_rockchip pcie@fe170000: failed to get pcie phy (ret=-19)
and you would need to know which PCIe controller that is before deciding
to ignore it. While after enabling the PHY driver, we are greeted with:
pcie_dw_rockchip pcie@fe170000: PCIe-2 Link Fail
which is a bit more acceptable (to me).
The other option would be to disable the PCIe2 PHYs/controllers in the
DT, which I'm not too fond of.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
|
The Jaguar SBC provides an M.2 slot connected to the pcie3 controller.
In contrast to a number of other boards the pcie-refclk is gpio-controlled,
so the necessary clock and is added to the list of pcie3 clocks.
Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
Reviewed-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Link: https://lore.kernel.org/r/20240423074956.2622318-1-heiko@sntech.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
[ upstream commit: 0ec7e1096332bc2b9bc881c21cfd234058f747b3 ]
(cherry picked from commit 76a89655ae740dddb57187b5b52071ed99187452)
Tested-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
|
ROCK Pi E v3.0 uses DDR4 SDRAM instead of DDR3 SDRAM used in v1.2x.
prepare new rk3328-rock-pi-e-v3.dts in u-boot which just includes
upstream rk3328-rock-pi-e.dts.
defconfig still uses
CONFIG_DEFAULT_FDT_FILE="rockchip/rk3328-rock-pi-e.dtb"
because v3.0 and prior are compatible.
Suggested-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
|
inno_poll passes the reg offset that is used by readl_poll_sleep_timeout
without any base addr.
Fix it.
Bug:
inno_hdmi_phy phy@ff430000: Pre-PLL locking failed
inno_hdmi_phy phy@ff430000: PHY: Failed to power on phy@ff430000: -110.
failed to power on phy (ret=-110)
inno_hdmi_phy phy@ff430000: Pre-PLL locking failed
inno_hdmi_phy phy@ff430000: PHY: Failed to power on phy@ff430000: -110.
failed to power on phy (ret=-110)
Fixes: aa2271184603 ("phy: rockchip: Add Rockchip INNO HDMI PHY driver")
Suggested-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Jagan Teki <jagan@edgeble.ai>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
|
No meaningful changes were made to this SoM since February 2021. Nobody
from Theobroma has booted anything recent on that product since July
2021 at the latest. The product isn't available to buy anymore and
disappeared from our website.
This product is therefore unmaintained and it would be disingenuous to
say the opposite, so drop support for RK3368 Lion.
If you're a user of Lion, feel free to revert this patch or contact our
sales/support department.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Acked-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
|
It turns out only Puma had a working git:// URL. Though that is now
fixed, having HTTPS URLs make it easier to directly reach our cgit
webserver to check what's up without having to change the URL manually.
Depending on your terminal settings, this also makes it possible to
open the link from it.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
|
On Puma v2.1 with a KSZ9031, the Ethernet PHY often doesn't detect the
link in the 4-second default timeout.
After some boot-loop test for about a thousand boots, 70% were below
10s, 90% below 15s and 100% below 30s. Let's play it safe and make it
30s so that hopefully all links that should be detected are.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
|
fix following error found by clang:
CC arch/arm/mach-rockchip/cpu-info.o
arch/arm/mach-rockchip/cpu-info.c:23:13: error: incomplete definition of type 'struct rockchip_cru'
23 | switch (cru->glb_rst_st) {
| ~~~^
./arch/arm/include/asm/arch-rockchip/clock.h:181:8: note: forward declaration of 'struct rockchip_cru'
181 | struct rockchip_cru;
| ^
1 error generated.
Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
|
Commit 2ce40542e0eb ("power: rk8xx: properly print all supported PMICs
name") fixed all PMICs name that were broken but broke the only one that
was not broken already: RK808. This one is a special case because the ID
registers are marked as reserved and always return 0, so the variant
cannot be derived the same way it is done for other PMICs from Rockchip.
Fixes: 2ce40542e0eb ("power: rk8xx: properly print all supported PMICs name")
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
|
|
In commit 100f489f58a6 ("rockchip: rk3399: Fix loading FIT from SD-card
when booting from eMMC"), the spi1 bootph properties were mistakenly
removed meaning, so re-add them back to fix SPI-NOR flash not being
found in U-Boot pre-reloc as required for RK3399 Puma.
Fixes: 100f489f58a6 ("rockchip: rk3399: Fix loading FIT from SD-card when booting from eMMC")
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
|
Enable the IO domain on Ringneck. Based on the current HW design, this
should do nothing else than making sure vccio6 iodomain is controlled by
the GRF and not GPIO0B6.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
|
Port the PX30 part of the Rockchip IO Domain driver from Linux.
This differs from linux version in that the io iodomain bit is enabled
in the write ops instead of in an init ops as in linux, this way we can
avoid keeping a full state of all supplies that have been configured.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
|
There are some sub-nodes under the grf DT nodes, so add bind callback
function in syscon_px30 driver to scan them recursively.
Fixes: e9ccb2f526ed ("rockchip: add px30 architecture core")
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
|
The Haikou Devkit exposes 4 buttons over GPIO so let's enable their
support so their status can be queried from the `button` command from
the CLI.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
|
PX30 supports ARMv8 Cryptography Extensions so let's enable it by
default for all PX30 to make FIT verification when enabled much faster.
While A35 shouldn't be impacted by ARMV8_SET_SMPEN cache coherency
according to the Kconfig help text, let's enable it just in case since
it exists in the documentation[1].
For u-boot part of the FIT image, it is now taking 5ms against currently
35ms. fdt-1 check lowered from 3ms to <1ms. atf-1 from 6ms to <1ms.
[1] https://developer.arm.com/documentation/100236/0100/register-descriptions/aarch64-system-registers/cpu-extended-control-register--el1?lang=en
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
|
This enables FIT verification in SPL for its payload (bl31, u-boot.itb,
...). This makes PX30 Ringneck match what happens on other Theobroma
boards.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
|
USB gadget simply doesn't work right now on PX30. Tested on PX30 EVB and
PX30 Ringneck with Linux mainline and Rockchip 5.10 Linux as well as
U-Boot.
We don't want to our users to assume that USB gadget is supported on Q7
USB P1 on Ringneck Haikou, so let's remove its support, which also
removes the ums CLI command, fastboot and Android image booting
support.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
|
|
The scan_part() function uses a struct uuid to store the little-endian
partition type GUID, but this structure should be used only to contain a
big-endian UUID. Use an efi_guid_t instead and use guidcmp() for the
comparison.
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
|
|
Move the guidcmp() and guidcpy() functions to efi.h, near the definition of
the efi_guid_t type those functions deal with.
Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Tom Rini <trini@konsulko.com>
|
