June 2024 - U-Boot

[PATCH v2 0/5] bootstd: Add Android support
by Mattijs Korpershoek 24 Jul '24

24 Jul '24

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/84cceb912bccd7cd… [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_… [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/an… Signed-off-by: Mattijs Korpershoek <mkorpershoek(a)baylibre.com> --- Changes in v2: - Dropped patch 2/6 boot: android: Add image_android_get_version() (Igor) - Fixed multi-line comment style (Igor, Simon) - Added dependency on CMD_FASTBOOT for BOOTMETH_ANDROID (Igor) - Fixed various resource leaks (Igor) - Fixed bootmeth_priv dangling pointer on error cases (Igor) - Updated test instructions in commit message for patch 6/6 - Added __weak impl of get_avendor_bootimg_addr() in patch 1 (dropped Igor's review because of this change) - Added extra info in Kconfig to detail MMC limitation (Simon) - Fixed typo Bootmethod->Bootmeth (Simon) - Documented android_priv structure (Simon) - Demoted various messages from printf() to log_debug (Simon) - Fixed some lines too long (Simon) - Added function documentation to read_slotted_partition() (Simon) - Added some doc about avb extra_args being modified (Simon) - Link to v1: https://lore.kernel.org/r/20240606-bootmeth-android-v1-0-0c69d4457cc5@bayli… --- Mattijs Korpershoek (5): boot: android: Provide vendor_bootimg_addr in boot_get_fdt() bootstd: Add bootflow_iter_check_mmc() helper android: boot: Add set_abootimg_addr() and set_avendor_bootimg_addr() bootstd: Add a bootmeth for Android bootstd: Add test for bootmeth_android MAINTAINERS | 7 + arch/sandbox/dts/test.dts | 8 + boot/Kconfig | 16 ++ boot/Makefile | 2 + boot/bootflow.c | 12 + boot/bootmeth_android.c | 553 ++++++++++++++++++++++++++++++++++++++++++++++ boot/bootmeth_android.h | 29 +++ boot/image-android.c | 5 + boot/image-fdt.c | 2 +- cmd/abootimg.c | 10 + configs/sandbox_defconfig | 2 +- doc/develop/bootstd.rst | 6 + include/bootflow.h | 9 + include/image.h | 14 ++ test/boot/bootflow.c | 65 +++++- test/py/tests/test_ut.py | 76 +++++++ 16 files changed, 811 insertions(+), 5 deletions(-) --- base-commit: f9886bc60f42d5bcfcfa4e474af7dc230400b6be change-id: 20240605-bootmeth-android-bfc8596e9367 Best regards, -- Mattijs Korpershoek <mkorpershoek(a)baylibre.com>

6 26

[PATCH 0/3] k3-j721e: Enable OF_UPSTREAM for J721E
by Neha Malcom Francis 24 Jul '24

24 Jul '24

This series was plucked out from the larger series [1] that did some templating reformatting and also enabled OF_UPSTREAM for J721E. The former has been kept aside till all the platforms affected have moved to using OF_UPSTREAM to have less conflicts while merging. Patches split J721E EVM and J721E SK to using separate builds, as well as enable OF_UPSTREAM for both the platforms. Boot logs: https://gist.github.com/nehamalcom/8f326376b6c6b1196084721405159bb9 [1] https://lore.kernel.org/all/20240322131011.1029620-1-n-francis@ti.com/ Neha Malcom Francis (3): arm: dts: k3-j721e-r5*: Introduce k3-j721e-r5.dtsi configs: j721e_sk: Move to separate defconfig for J721E SK board arm: dts: k3-j721e: Move to OF_UPSTREAM arch/arm/dts/Makefile | 4 +- arch/arm/dts/k3-j721e-binman.dtsi | 101 +- .../k3-j721e-common-proc-board-u-boot.dtsi | 14 +- arch/arm/dts/k3-j721e-common-proc-board.dts | 976 ------ arch/arm/dts/k3-j721e-main.dtsi | 2741 ----------------- arch/arm/dts/k3-j721e-mcu-wakeup.dtsi | 681 ---- arch/arm/dts/k3-j721e-r5-beagleboneai64.dts | 78 +- .../arm/dts/k3-j721e-r5-common-proc-board.dts | 75 +- arch/arm/dts/k3-j721e-r5-sk.dts | 75 +- arch/arm/dts/k3-j721e-r5.dtsi | 80 + arch/arm/dts/k3-j721e-sk-u-boot.dtsi | 41 +- arch/arm/dts/k3-j721e-sk.dts | 1074 ------- arch/arm/dts/k3-j721e-som-p0.dtsi | 446 --- arch/arm/dts/k3-j721e-thermal.dtsi | 75 - arch/arm/dts/k3-j721e.dtsi | 176 -- board/ti/j721e/MAINTAINERS | 2 + configs/j721e_evm_a72_defconfig | 5 +- configs/j721e_evm_r5_defconfig | 2 +- configs/j721e_sk_a72_defconfig | 9 + configs/j721e_sk_r5_defconfig | 10 + 20 files changed, 147 insertions(+), 6518 deletions(-) delete mode 100644 arch/arm/dts/k3-j721e-common-proc-board.dts delete mode 100644 arch/arm/dts/k3-j721e-main.dtsi delete mode 100644 arch/arm/dts/k3-j721e-mcu-wakeup.dtsi create mode 100644 arch/arm/dts/k3-j721e-r5.dtsi delete mode 100644 arch/arm/dts/k3-j721e-sk.dts delete mode 100644 arch/arm/dts/k3-j721e-som-p0.dtsi delete mode 100644 arch/arm/dts/k3-j721e-thermal.dtsi delete mode 100644 arch/arm/dts/k3-j721e.dtsi create mode 100644 configs/j721e_sk_a72_defconfig create mode 100644 configs/j721e_sk_r5_defconfig -- 2.34.1

5 7

[PATCH v2 0/2] virtio_gpu driver and relevant fix
by Jiaxun Yang 21 Jul '24

21 Jul '24

Hi all, This series added support for virtio-gpu device, it has been tested on QEMU riscv64 and aarch64. I also fixed a problem in EFI GOP so it works with EFI applications as well. There is a problem remaining. virtio_init() is being called too late to allow virtio-gpu to be selected as a vidconsole. My current appraoch is to register virtio_init in init_sequence_r, just after pci_init. Is this a viable approach? Should I introduce a config like CONFIG_VIRTIO_INIT_R to allow it to be selected by boards? Thanks Signed-off-by: Jiaxun Yang <jiaxun.yang(a)flygoat.com> --- Changes in v2: - Fix left over in previous version (endian, unused variable) - Fix Kconfig text - Link to v1: https://lore.kernel.org/r/20240517-virtio_gpu-v1-0-6353b87472c7@flygoat.com --- Jiaxun Yang (2): virtio: New virtio_gpu driver efi: gop: Mark pixel_format as BLTONLY if we have sync hook drivers/virtio/Kconfig | 29 +++ drivers/virtio/Makefile | 1 + drivers/virtio/virtio-uclass.c | 1 + drivers/virtio/virtio_gpu.c | 302 +++++++++++++++++++++++++++++ drivers/virtio/virtio_gpu.h | 428 +++++++++++++++++++++++++++++++++++++++++ include/efi_api.h | 1 + include/virtio.h | 4 +- lib/efi_loader/efi_gop.c | 8 +- 8 files changed, 772 insertions(+), 2 deletions(-) --- base-commit: 21aa37ec1cd4a12e01e0e863ec9e99d703ce4d52 change-id: 20240513-virtio_gpu-abb4de685808 Best regards, -- Jiaxun Yang <jiaxun.yang(a)flygoat.com>

2 7

[PATCH] riscv: dts: jh7110: Enable PLL node in SPL
by Bo Gan 19 Jul '24

19 Jul '24

Previously PLL node was missing from SPL dts. This caused BUS_ROOT to stay on OSC clock (24Mhz). As a result, all peripherals have to run at a much lower frequency, and loading from sdcard/emmc is slow. Thus, enabling PLL node in dts to fix this. Signed-off-by: Bo Gan <ganboing(a)gmail.com> --- arch/riscv/dts/jh7110-u-boot.dtsi | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/arch/riscv/dts/jh7110-u-boot.dtsi b/arch/riscv/dts/jh7110-u-boot.dtsi index 2f560e7..c09d5c9 100644 --- a/arch/riscv/dts/jh7110-u-boot.dtsi +++ b/arch/riscv/dts/jh7110-u-boot.dtsi @@ -93,6 +93,10 @@ bootph-pre-ram; }; +&pllclk { + bootph-pre-ram; +}; + &S7_0 { status = "okay"; }; -- 2.7.4

4 10

[PATCH v1 0/2] cmd: ubi: check 'updating' before calling ubi_more_update_data()
by Martin Kurbanov 19 Jul '24

19 Jul '24

If 0 is passed to the 'bytes' parameter in the ubi_start_update(), there is no need to call the ubi_more_update_data(). Otherwise, there will be a double-free of 'vol->upd_buf'. Also check that the ubi_start_update() was called before calling the ubi_more_update_data(). Martin Kurbanov (2): cmd: ubi: remove redundant initializations cmd: ubi: check 'updating' before calling ubi_more_update_data() cmd/ubi.c | 21 +++++++++++++++------ 1 file changed, 15 insertions(+), 6 deletions(-) -- 2.43.2

1 3

[PATCH] bootstd: cros: store partition type in an efi_guid_t
by Vincent Stehlé 18 Jul '24

18 Jul '24

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. Signed-off-by: Vincent Stehlé <vincent.stehle(a)arm.com> Cc: Simon Glass <sjg(a)chromium.org> Cc: Tom Rini <trini(a)konsulko.com> --- boot/bootmeth_cros.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/boot/bootmeth_cros.c b/boot/bootmeth_cros.c index f015f2e1c75..1f83c14aeab 100644 --- a/boot/bootmeth_cros.c +++ b/boot/bootmeth_cros.c @@ -148,7 +148,7 @@ static int scan_part(struct udevice *blk, int partnum, { struct blk_desc *desc = dev_get_uclass_plat(blk); struct vb2_keyblock *hdr; - struct uuid type; + efi_guid_t type; ulong num_blks; int ret; @@ -161,7 +161,7 @@ static int scan_part(struct udevice *blk, int partnum, /* Check for kernel partition type */ log_debug("part %x: type=%s\n", partnum, info->type_guid); - if (uuid_str_to_bin(info->type_guid, (u8 *)&type, UUID_STR_FORMAT_GUID)) + if (uuid_str_to_bin(info->type_guid, type.b, UUID_STR_FORMAT_GUID)) return log_msg_ret("typ", -EINVAL); if (memcmp(&cros_kern_type, &type, sizeof(type))) -- 2.43.0

4 8

[PATCH v2 0/5] FUSB302 USB-C controller support
by Sebastian Reichel 17 Jul '24

17 Jul '24

Hi, On ROCK 5B power is usually supplied via it's USB-C port. This port has the data lines connected to RK3588, VBUS connected to the input regulator and CC pins connected to FUSB302. FUSB302 is a USB-C controller, which can be accessed via I2C from RK3588. The USB-C controller is needed to figure out the USB-C cable orientation, but also to do USB PD communication. Thus it would be great to enable support for it in the operating system. But the USB-PD specification requires, that a device reacts to USB-PD messages send by the power-supply within around 5 seconds. If that does not happen the power-supply assumes, that the device does not support USB-PD. If a device later starts sending USB-PD messages it is considered an error, which is solved by doing a hard reset. A USB-PD hard reset means, that all supply voltages are removed for a short period of time. For boards, which are solely powered through their USB-C port, like the Radxa Rock 5B, this results in an machine reset. This is currently worked around by not describing the FUSB302 in the kernel DT, so nothing will ever speak USB-PD on the Rock 5B. This means 1. the USB-C port cannot be used at all 2. the board will be running via fallback supply, which provides limited power capabilities In order to avoid the hard reset, this adds FUSB302 support to U-Boot, so that we react to the power-supply's queries in time. The code, which is originally from the Linux kernel, consists of two parts: 1. the tcpm state machine, which implements the Type C port manager state machine as described in the USB PD specification 2. the fusb302 driver, which knows about specific registers Especially the first part has been heavily modified compared to the kernel, which makes use of multiple delayed works and threads. For this I used a priorly ported version from Rockchip, removed their hacks and any states not necessary in U-Boot (e.g. audio accessory support). Changes since PATCHv1: * tcpm: split uclass specific code to tcpm-uclass * tcpm_print_info: move printing part to cmd/tcpm.c * tcpm_print_info: report more information - PD revision - Cable orientation - Power role - Data role - Print TCPM state based on connection status * tcpm: use "struct udevice *dev" instead of "struct tcpm_port *port" as function argument in most places and drop dev from the tcpm_port struct * tcpm: avoid useless kzalloc + copy + free for incoming events * tcpm: use dev_get_uclass_plat() for tcpm_port * tcpm: run tcpm_port_init() and tcpm_poll_event() from UCLASS post_probe() * tcpm/fusb302: get rid of tcpc_dev by using dm_tcpm_ops() for the function pointers and introducing get_connector_node() for the ofnode * fusb302: use "struct udevice *dev" instead of "struct fusb302_chip *chip" as function argument and drop dev from the fusb302_chip struct * fusb302: drop multiple unused members from fusb302_chip * fusb302: directly use udelay instead of usleep_range define * fusb302: use fusb302_ prefix for all functions. Afterwards tcpm_ prefix is only used for the tcpm code itself * fusb302: move fusb302_poll_event() to avoid forward defintion * fusb302: drop probe function * fusb302: drop unused LOG_BUFFER defines * roughly 20% of all lines of the series changed between v1 and v2, so I did not collect the Tested-by from Soeren Moch Greetings, -- Sebastian Sebastian Reichel (5): usb: tcpm: add core framework usb: tcpm: fusb302: add driver board: rock5b-rk3588: add USB-C controller support board: rock5b-rk3588: enable USB-C in operating system MAINTAINERS: add TCPM section MAINTAINERS | 8 + Makefile | 1 + arch/arm/dts/rk3588-rock-5b-u-boot.dtsi | 28 + board/radxa/rock5b-rk3588/Makefile | 6 + board/radxa/rock5b-rk3588/rock5b-rk3588.c | 33 + cmd/Kconfig | 7 + cmd/Makefile | 1 + cmd/tcpm.c | 142 ++ configs/rock5b-rk3588_defconfig | 5 + drivers/usb/Kconfig | 2 + drivers/usb/tcpm/Kconfig | 16 + drivers/usb/tcpm/Makefile | 4 + drivers/usb/tcpm/fusb302.c | 1333 ++++++++++++ drivers/usb/tcpm/fusb302_reg.h | 177 ++ drivers/usb/tcpm/tcpm-internal.h | 174 ++ drivers/usb/tcpm/tcpm-uclass.c | 102 + drivers/usb/tcpm/tcpm.c | 2251 +++++++++++++++++++++ include/dm/uclass-id.h | 1 + include/usb/pd.h | 516 +++++ include/usb/tcpm.h | 99 + 20 files changed, 4906 insertions(+) create mode 100644 board/radxa/rock5b-rk3588/Makefile create mode 100644 board/radxa/rock5b-rk3588/rock5b-rk3588.c create mode 100644 cmd/tcpm.c create mode 100644 drivers/usb/tcpm/Kconfig create mode 100644 drivers/usb/tcpm/Makefile create mode 100644 drivers/usb/tcpm/fusb302.c create mode 100644 drivers/usb/tcpm/fusb302_reg.h create mode 100644 drivers/usb/tcpm/tcpm-internal.h create mode 100644 drivers/usb/tcpm/tcpm-uclass.c create mode 100644 drivers/usb/tcpm/tcpm.c create mode 100644 include/usb/pd.h create mode 100644 include/usb/tcpm.h -- 2.43.0

6 16

[PATCH v3 00/12] MIPS: Boston: Various enhancements
by Jiaxun Yang 17 Jul '24

17 Jul '24

Hi all, This is a huge series which promoted MIPS/Boston target into a usable state, with fixes to drivers and general framework issues I found in this process. I also converted the target to OF_UPSTREAM. This target is covered by QEMU, to test on QEMU: ``` make boston64r6el_defconfig make qemu-system-mips64el -M boston -cpu I6500 -bios ./u-boot.bin -nographic ``` This is my first u-boot contribution, please kindly advise if you have any comments. Thanks Signed-off-by: Jiaxun Yang <jiaxun.yang(a)flygoat.com> --- Changes in v3: - Slight change in clk_boston probe order (Jonas) - Link to v2: https://lore.kernel.org/r/20240516-boston-v2-0-77938800d1dd@flygoat.com Changes in v2: - Drop "[PATCH 09/13] syscon: Probe device first in syscon_get_regmap" in flavour of fixing the driver device life cycle (Jonas) - Link to v1: https://lore.kernel.org/r/20240513-boston-v1-0-fac96938417e@flygoat.com --- Jiaxun Yang (12): pci: xilinx: Handle size of ecam region properly pci: auto: Reduce bridge mem alignment boundary for boston pci: Enable PCI_MAP_SYSTEM_MEMORY when ARCH_MAP_SYSMEM is not set ahci: DMA addressing fixes ahci: dwc_ahsata: Generalize the driver MIPS: Provide dummy acpi_table.h MIPS: boston: Imply various options MIPS: boston: Provide default env vars clk: boston: Allow to get regmap from parent device dts/upstream: Add Makefile for MIPS MIPS: boston: Migrate to OF_UPSTREAM mailmap: Update email for Paul Burton .mailmap | 3 +- arch/mips/Kconfig | 28 +++++ arch/mips/dts/Makefile | 1 - arch/mips/dts/boston-u-boot.dtsi | 10 ++ arch/mips/dts/img,boston.dts | 222 ------------------------------------- arch/mips/include/asm/acpi_table.h | 10 ++ board/imgtec/boston/Kconfig | 4 + board/imgtec/boston/MAINTAINERS | 3 +- board/imgtec/boston/boston.env | 9 ++ board/imgtec/malta/MAINTAINERS | 2 +- configs/boston32r2_defconfig | 2 +- configs/boston32r2el_defconfig | 2 +- configs/boston32r6_defconfig | 2 +- configs/boston32r6el_defconfig | 2 +- configs/boston64r2_defconfig | 2 +- configs/boston64r2el_defconfig | 2 +- configs/boston64r6_defconfig | 2 +- configs/boston64r6el_defconfig | 2 +- drivers/ata/ahci.c | 34 +++--- drivers/ata/dwc_ahsata.c | 82 +++++++++----- drivers/ata/dwc_ahsata_priv.h | 2 - drivers/clk/clk_boston.c | 19 ++-- drivers/pci/Kconfig | 10 ++ drivers/pci/pci_auto.c | 16 +-- drivers/pci/pcie_xilinx.c | 53 ++++++--- dts/upstream/src/mips/Makefile | 14 +++ include/ahci.h | 4 +- 27 files changed, 232 insertions(+), 310 deletions(-) --- base-commit: c8ffd1356d42223cbb8c86280a083cc3c93e6426 change-id: 20240513-boston-45ef6edc219f Best regards, -- Jiaxun Yang <jiaxun.yang(a)flygoat.com>

5 27

Request for hosting a boot-firmware repository in u-boot git (denx and GitHub)
by Nishanth Menon 17 Jul '24

17 Jul '24

Hi Team, We have briefly discussed this topic on IRC[1]. I would like to propose a new boot-firmware repository similar to the Linux-firmware repository under the aegis of u-boot hosting. In addition to TI, it looks like some NXP[2] and Rockchip[3] platforms seem to require additional closed-source/open-source binaries to have a complete bootable image. Distribution rights and locations of these binaries are challenging, and there needs to be a standard for how and where they are hosted for end users. Further, looking ahead to future architectures: * IP firmware: More and more IP vendors are embedding their own "specialized controllers" and require firmware for the operation (similar to Rockchip's DDR controller, I guess), * boot stage firmware: Additional stages of the boot process involve vendor intermediate firmware, such as power configuration. * Security enclave binaries: While I see a few folks trying to have an open-source s/w architecture, many PKA and PQC systems still require prop binaries for IP reasons. NOTE: I am not judging any company(including TI) for reasons why some firmware is proprietary, but I hate to have the end users and other system (distro) maintainers have to deal with hell trying to make the life of end users easy to live with. In the case of TI's K3 architecture devices, we have two binary blobs that are critical for the boot process. 1. TIFS Firmware / DMSC firmware[4]—This is the security enclave firmware. It is often encrypted, and sources are not public (due to various business/regulatory reasons). 2. DM Firmware[5] - There is a source in public in some cases and binary only in others - essentially limited function binary to be put up in the device management uC. In cases where the source is available, the build procedure is, in my personal opinion, pretty arcane, and even though in theory it is practical, in practice, not friendly - efforts are going to simplify it, even probably integrate it with a more opensource ecosystem, but that is talking "look at the tea leaves" stuff. 3. Low Power Management (LPM) binaries: tifs stub: another encrypted binary that gives the tifs system context restore logic before retrieving tifs firmware and a corresponding DM restoration binary. All told, this is not unlike the situation that necessitated the creation of a Linux firmware repository. Options that I see: 1. Let the status quo be - SoC vendors maintain random locations and random rules to maintain boot firmware. 2. Ask Linux-firmware to host the binaries in a single canonical location 3. Host a boot-firmware repository - u-boot repo may be the more logical location. * (1) isn't the correct answer. * (2) Though I haven't seen any policy from the Linux-firmware community mandating anything of the form, the binaries we are talking of may not belong to Linux-firmware as they aren't strictly speaking something Linux kernel will load (since the bootloader has that responsibility), and in some cases may not even directly talk to (security enclave or DDR firmware stuff). I am adding Josh to this mail to see if he has any opinions on the topic (but keeping from cross posting on linux-firmware list, unless folks feel it is OK). On (3): Proposal: * Create a boot firmware repository in Denx and/or GitHub (if financials are a hurdle, I hope we can solve it as a community). * Limit binaries only to those consumed part of the u-boot scope. * Limit binaries only to those that do not have an opensource project (Trusted Firmware-A/M, OP-TEE, etc..) or depend entirely on vendor source or are binary only in nature (subject to licensing terms below) * Limit binaries to some pre-established size to prevent repository explosion - say, 512Kib? * Follow the same rules of integration and licensing guidelines as Linux-firmware[6]. * Similar rules as Linux-firmware guidelines of ABI backward and forward compatibility. * Set a workflow update flow and a compatibility requirements document If we agree to have boot firmware under the stewardship of u-boot, we should also set other rules, which is excellent to discuss. Thoughts? [1] https://libera.irclog.whitequark.org/u-boot/2024-06-13#36498796; [2] https://docs.nxp.com/bundle/AN14093/page/topics/build_the_u-boot.html [3] https://bbs.t-firefly.com/forum.php?mod=viewthread&tid=2236 [4] https://git.ti.com/cgit/processor-firmware/ti-linux-firmware/tree/ti-sysfw?… [5] https://git.ti.com/cgit/processor-firmware/ti-linux-firmware/tree/ti-dm?h=t… [6] https://docs.kernel.org/next/driver-api/firmware/firmware-usage-guidelines.… -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D

8 20

[PATCH next 0/2] rockchip: theobroma: use HTTPS for git URLs and drop RK3368 Lion support
by Quentin Schulz 17 Jul '24

17 Jul '24

Nobody at Theobroma has booted Lion since at least July 2021 and the last meaningful changes were made in February 2021. The product isn't listed on our website anymore. Therefore let's remove its support. Additionally, migrate git URLs in MAINTAINERS to use https:// instead of git:// as it's more user-friendly (and also that git:// was only supported for Puma repo until yesterday). Signed-off-by: Quentin Schulz <quentin.schulz(a)cherry.de> --- Quentin Schulz (2): rockchip: theobroma-systems: migrate git URLs to HTTPS rockchip: remove support for Theobroma Systems RK3368 Lion arch/arm/dts/rk3368-lion-haikou-u-boot.dtsi | 119 -------- arch/arm/dts/rk3368-lion-haikou.dts | 144 ---------- arch/arm/dts/rk3368-lion.dtsi | 318 ---------------------- arch/arm/mach-rockchip/rk3368/Kconfig | 22 -- board/theobroma-systems/jaguar_rk3588/MAINTAINERS | 2 +- board/theobroma-systems/lion_rk3368/Kconfig | 18 -- board/theobroma-systems/lion_rk3368/MAINTAINERS | 10 - board/theobroma-systems/lion_rk3368/README | 78 ------ board/theobroma-systems/puma_rk3399/MAINTAINERS | 2 +- board/theobroma-systems/ringneck_px30/MAINTAINERS | 2 +- board/theobroma-systems/tiger_rk3588/MAINTAINERS | 2 +- configs/lion-rk3368_defconfig | 110 -------- doc/board/rockchip/rockchip.rst | 1 - include/configs/lion_rk3368.h | 16 -- 14 files changed, 4 insertions(+), 840 deletions(-) --- base-commit: e124e630ad694327e33d6513e43951793e827d3a change-id: 20240620-tsd-http-git-clone-53c0ea69adbe Best regards, -- Quentin Schulz <quentin.schulz(a)cherry.de>

6 10