- Jul 19, 2024
-
-
Heinrich Schuchardt authored
Move the information about out-of-tree building from README to the generated HTML documentation. Signed-off-by:
Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by:
Simon Glass <sjg@chromium.org>
-
Heinrich Schuchardt authored
The auto-generated load options for media device do not contain a partition node. We cannot expect the simple file protocol here. Get the partition device-path via the loaded image protocol. Fixes: e91b68fd ("efi_loader: load distro dtb in bootmgr") Reported-by:
E Shattow <lucent@gmail.com> Signed-off-by:
-
add missing table of content links, make alphabetical Signed-off-by:
Sam Povilus <sam.povilus@amd.com> Reviewed-by:
-
Before 9d075006 (doc: Move external FIT docs into the main body), the FIT property data-size was not a mandatory property and still it is not expected to be set alongside the data property. Move the data-size property to the "Conditionally mandatory property" section, where it actually belongs. Signed-off-by:
-
- Jul 18, 2024
-
-
Tom Rini authored
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
-
Tom Rini authored
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:
-
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:
-
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:
-
Some bootflows might be able to only boot from MMC devices. Add a helper function these bootflows can use. Reviewed-by:
-
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: -
[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 4fb7e570. Cc: Masahisa Kojima <kojima.masahisa@socionext.com> Signed-off-by:
-
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: -
[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: -
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:
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-rockchipTom Rini authored
- 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:
-
Tom Rini authored
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:
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: d3c3606c ("timer: MediaTek: add timer driver for MediaTek SoCs") Signed-off-by:
Christian Marangi <ansuelsmth@gmail.com>
-
Tom Rini authored
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>
-
- Jul 17, 2024
-
-
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:
-
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:
-
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: 50e54e80 ("phy: rockchip: snps-pcie3: Add support for RK3588") Signed-off-by:Sebastian Kropatsch <seb-dev@mail.de> Reviewed-by:
-
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: 50e54e80 ("phy: rockchip: snps-pcie3: Add support for RK3588") Signed-off-by: -
Several identifiers use "rochchip" instead of "rockchip". Fix this by replacing every instance of "rochchip" with "rockchip". Signed-off-by:
-
Replace "rochchip" by "rockchip" in two instances. Signed-off-by:
-
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: -
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:
-
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:
Heiko Stuebner <heiko@sntech.de> Tested-by:
-
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:
-
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:
-
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:
-
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: aa227118 ("phy: rockchip: Add Rockchip INNO HDMI PHY driver") Suggested-by:
Jagan Teki <jagan@edgeble.ai> Reviewed-by:
-
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:
-
