Re: [PATCH] cmd: add a fetch utility

Am 8. August 2024 18:24:24 MESZ schrieb Caleb Connolly : >While U-Boot does a pretty good job at printing information at startup >about what hardware it's running on, it can be hard to take pretty >pictures of this to show off on the internet (by far the most >important aspect of porting a devi

Re: [PATCH] cmd: add a fetch utility

On 8/8/24 18:24, Caleb Connolly wrote: While U-Boot does a pretty good job at printing information at startup about what hardware it's running on, it can be hard to take pretty pictures of this to show off on the internet (by far the most important aspect of porting a device in 2024!). Add a

Re: [PATCH v3] config: Add 'update_bootimg' command to update flash.bin on Phytec's imx8mm

Hello Lukasz Am Donnerstag, dem 08.08.2024 um 12:25 +0200 schrieb Lukasz Majewski: > Hi Teresa, > > > Hello Lukasz, > > > > Am Mittwoch, dem 07.08.2024 um 13:04 +0200 schrieb Lukasz Majewski: > > > Hi Benjamin, > > >   > > > > Hi Lukasz, > > > > > > > > On 06.08.24 10:11, Lukasz Majewski wrote

Re: [PATCH v2 1/1] disk: add TegraPT support

пт, 9 серп. 2024 р. о 08:49 Heinrich Schuchardt пише: > > > > Am 7. August 2024 14:10:24 MESZ schrieb Svyatoslav Ryhel : > >TegraPT is compatible with EFI part but it can't pass Protective MBR check. > >Skip this check if CONFIG_TEGRA_PARTITION is enabled, storage uclass is MMC > >and devnum is 0.

Re: [PATCH] cmd: sf: prevent overwriting the reserved memory

Hi Simon, On 8/8/24 16:28, Simon Glass wrote: Hi Michal, On Wed, 7 Aug 2024 at 23:31, Michal Simek wrote: On 8/7/24 16:36, Simon Glass wrote: Hi Prasad, On Tue, 6 Aug 2024 at 23:05, Kummari, Prasad wrote: Hi Glass, -Original Message- From: Simon Glass Sent: Wednesday, Augus

Re: [PATCH v2 1/1] disk: add TegraPT support

Am 7. August 2024 14:10:24 MESZ schrieb Svyatoslav Ryhel : >TegraPT is compatible with EFI part but it can't pass Protective MBR check. >Skip this check if CONFIG_TEGRA_PARTITION is enabled, storage uclass is MMC >and devnum is 0. Note, eMMC on supported devices MUST be aliased to mmc0. Why wou

Re: [PATCH] cmd: sf: prevent overwriting the reserved memory

Hi Tom, On 8/8/24 17:46, Tom Rini wrote: On Thu, Aug 08, 2024 at 01:18:44PM +0200, Michal Simek wrote: On 8/8/24 08:22, Sughosh Ganu wrote: On Thu, 8 Aug 2024 at 11:05, Michal Simek wrote: On 8/7/24 23:12, Tom Rini wrote: On Tue, Aug 06, 2024 at 05:37:00PM +0530, Prasad Kummari wrote:

Re: [PATCH] usb: dwc3-generic: fix CONFIG_DM_REGULATOR-off case

On 08.08.24 16:27, Caleb Connolly wrote: > Hi Jan, > > On 08/08/2024 10:51, Jan Kiszka wrote: >> From: Jan Kiszka >> >> When DM_REGULATOR is disabled, all calls will return -ENOSYS. Account >> for that so that targets like the IOT2050 will work again. >> >> Fixes: de451d5d5b6f ("usb: dwc3-generic

[PATCH] versal2: Update the sys prompt name

versal2 refers as "Versal Gen 2" as a generic approved name so using the same as u-boot prompt name for all versal2 defconfig Signed-off-by: Love Kumar --- configs/amd_versal2_mini_defconfig | 2 +- configs/amd_versal2_mini_emmc_defconfig | 2 +- configs/amd_versal2_mini_ospi_defconfig | 2

Re: [PATCH V8 0/7] Low Power Mode: Package TIFS Stub in BeaglePlay

On Mon, 05 Aug 2024 19:59:30 +0530, Dhruva Gole wrote: > This series aims to add documentation around the boot flow and tispl > packaging details regarding the TIFS Stub. While at it, also refactors the > k3 common docs to add more labels to provide more granularity on how we > include chunks from

Re: [PATCH 1/5] arch: arm: dts: k3-j784s4-r5-evm: Add missing fss range

On 8/8/24 4:29 PM, Jonathan Humphreys wrote: Upstream DTS added explicit ranges to the fss node. It did not include the 32 bit memory space needed by the R5 to access OSPI. With the upstream DTS sync, OSPI boot no longer works. Adding the missing range here. It is also being added in the upstr

Re: [PATCH] cmd: add a fetch utility

Hi Caleb, On Thu, 8 Aug 2024 at 10:32, Caleb Connolly wrote: > > While U-Boot does a pretty good job at printing information at startup > about what hardware it's running on, it can be hard to take pretty > pictures of this to show off on the internet (by far the most > important aspect of portin

[PATCH v7 11/11] test: lib/uuid: add tests for UUID version/variant bits

Add a test to check the version/variant bits of v4 and v5 UUIDs. Signed-off-by: Caleb Connolly --- test/lib/uuid.c | 38 ++ 1 file changed, 38 insertions(+) diff --git a/test/lib/uuid.c b/test/lib/uuid.c index 2c6cfd42ddc3..bbaf821f007d 100644 --- a/test/lib/

[PATCH v7 10/11] test: lib/uuid: add unit tests for dynamic UUIDs

Add some basic unit tests to validate that the UUID generation behaves as expected. This matches the implementation in efi_loader for sandbox and a Qualcomm board and should catch any regressions. Acked-by: Ilias Apalodimas Signed-off-by: Caleb Connolly --- test/lib/uuid.c | 82

[PATCH v7 09/11] tools: mkeficapsule: support generating dynamic GUIDs

Add support for generating GUIDs that match those generated internally by U-Boot for capsule update fw_images when using dynamic UUIDs. Dynamic UUIDs in U-Boot work by taking a namespace UUID and hashing it with the board compatible and fw_image name. This feature just provides a way to determine

[PATCH v7 08/11] tools: mkeficapsule: use u-boot UUID library

Replace the use of libuuid with U-Boot's own UUID library. This prepares us to add support for generating v5 GUIDs. Signed-off-by: Caleb Connolly --- tools/Makefile | 8 tools/mkeficapsule.c | 53 ++-- 2 files changed, 10 insertions

[PATCH v7 07/11] include: export uuid.h

Move this header to include/u-boot/ so that it can be used by external tools. Reviewed-by: Ilias Apalodimas Signed-off-by: Caleb Connolly --- arch/arm/mach-rockchip/board.c | 2 +- board/cobra5272/flash.c| 2 +- board/gardena/smart-gateway-mt7688/board.c | 2 +-

[PATCH v7 06/11] lib: uuid: supporting building as part of host tools

Adjust the UUID library code so that it can be compiled as part of a host tool. This removes the one redundant log_debug() call, as well as the incorrectly defined LOG_CATEGORY. In general this is a fairly trivial change, just adjusting includes and disabling list_guid. This will be used by a ne

[PATCH v7 05/11] sandbox: switch to dynamic UUIDs

Migrate sandbox over to generating it's capsule update image GUIDs dynamically from the namespace and board/image info. Update the reference and tests to use the new GUIDs. Acked-by: Ilias Apalodimas Signed-off-by: Caleb Connolly --- board/sandbox/sandbox.c | 16

[PATCH v7 04/11] doc: uefi: document dynamic UUID generation

Document how platforms can generate GUIDs at runtime rather than maintaining a list of UUIDs per-board. Reviewed-by: Ilias Apalodimas Signed-off-by: Caleb Connolly --- doc/develop/uefi/uefi.rst | 27 +++ 1 file changed, 27 insertions(+) diff --git a/doc/develop/uefi/uef

[PATCH v7 03/11] efi: add a helper to generate dynamic UUIDs

Introduce a new helper efi_capsule_update_info_gen_ids() which populates the capsule update fw images image_type_id field. This allows for determinstic UUIDs to be used that can scale to a large number of different boards and board variants without the need to maintain a big list. We call this fro

[PATCH v7 02/11] lib: uuid: add UUID v5 support

Add support for generating version 5 UUIDs, these are determistic and work by hashing a "namespace" UUID together with some unique data. One intended usecase is to allow for dynamically generate payload UUIDs for UEFI capsule updates, so that supported boards can have their own UUIDs without needin

[PATCH v7 01/11] efi: define struct efi_guid

This let's us forward declare efi_guid_t in the UUID code without pulling in efi.h Reviewed-by: Ilias Apalodimas Signed-off-by: Caleb Connolly --- include/efi.h | 2 +- tools/eficapsule.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/include/efi.h b/include/efi.h i

[PATCH v7 00/11] efi: CapsuleUpdate: support for dynamic UUIDs

/ CI run for this series: https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/pipelines/21944 --- Changes in v7: - Minor adjustments to fix CI on some 32-bit ARM platforms - Link to v6: https://lore.kernel.org/r/20240808-b4-dynamic-uuid-v6-0-9332e7237...@linaro.org Changes in v6:

[PATCH 7/7] doc: board/qualcomm: document rb3gen2 building/flashing

The process here is almost identical to the Dragonboard 410c, we've come full circle! Signed-off-by: Caleb Connolly --- doc/board/qualcomm/rb3gen2.rst | 53 ++ 1 file changed, 53 insertions(+) diff --git a/doc/board/qualcomm/rb3gen2.rst b/doc/board/qualco

[PATCH 6/7] configs: add qcm6490_defconfig

Introduce a defconfig for the RB3 Gen 2 and other QCM6490 boards with a dedicated uefi partition. These can replace EDK2 entirely with U-Boot. Signed-off-by: Caleb Connolly --- configs/qcm6490_defconfig | 18 ++ 1 file changed, 18 insertions(+) diff --git a/configs/qcm6490_defco

[PATCH 4/7] iommu: qcom-smmu: add sc7280-smmu-500 compatible

This soc doesn't have the generic compatible. Signed-off-by: Caleb Connolly --- drivers/iommu/qcom-hyp-smmu.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/iommu/qcom-hyp-smmu.c b/drivers/iommu/qcom-hyp-smmu.c index 7b646d840dd4..1b5a09bb7b39 100644 --- a/drivers/iommu/qcom-hyp-smm

[PATCH 5/7] qcom_defconfig: enable SC7280 clocks

Enable clocks on SC7280 Signed-off-by: Caleb Connolly --- configs/qcom_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/qcom_defconfig b/configs/qcom_defconfig index 24b71ba7be29..1a079264a554 100644 --- a/configs/qcom_defconfig +++ b/configs/qcom_defconfig @@ -44,8 +44,9 @@

[PATCH 3/7] dts: qcs6490-rb3gen2-u-boot: USB host mode

Adjust DTS so USB runs in host mode. The type-c port is the only supported port (since the others need PCIe). Booting from USB is possible with a powered type-c dock. Signed-off-by: Caleb Connolly --- arch/arm/dts/qcs6490-rb3gen2-u-boot.dtsi | 5 + 1 file changed, 5 insertions(+) diff --git

[PATCH 2/7] dts: qcs6490-rb3gen2-u-boot: add override dtsi

For running U-Boot as primary bootloader we must define the memory layout statically. Signed-off-by: Caleb Connolly --- arch/arm/dts/qcs6490-rb3gen2-u-boot.dtsi | 23 +++ 1 file changed, 23 insertions(+) diff --git a/arch/arm/dts/qcs6490-rb3gen2-u-boot.dtsi b/arch/arm/dts/q

[PATCH 1/7] clk/qcom: add initial clock driver for sc7280

We don't actually need any clocks to get UFS up and running, resets are useful though. Signed-off-by: Caleb Connolly --- drivers/clk/qcom/Kconfig| 8 +++ drivers/clk/qcom/Makefile | 1 + drivers/clk/qcom/clock-qcom.h | 1 + drivers/clk/qcom/clock-sc7280.c | 132

[PATCH 0/7] Qualcomm: add support for SC7280 and the RB3 Gen 2

Introduce support for the SC7280 platform and specifically the RB3 Gen 2 development board. The RB3 Gen 2 is the latest robotics board from Qualcomm, featuring a QCM6490 SoC (the same SoC found in the Fairphone 5), 6GB of RAM, and 128GB of UFS storage, as well as a whole lot of I/O. Most of the I

Re: [PATCH v6] board: rockchip: add Radxa ROCK 3 Model C

Hi, On 8/9/24 04:37, Maxim Moskalets wrote: From: Maxim Moskalets Based on rock-3a-rk3568_defconfig. Tested on v1.31 revision. Board Specifications: - Rockchip RK3566 - 1/2/4GB LPDDR4 2112MT/s - eMMC socket - uSD card slot - M.2 2230 Connector - GbE LAN with POE - 3.5mm jack with mic - HDMI 2

Re: [PATCH v2] usb: dwc3: support USB 3.1 controllers

Small ping, I think this patch slipped through the cracks. On 23/04/2024 16:15, Caleb Connolly wrote: The revision is different for these, add the additional check as in xhci-dwc3 core_init code. Equivalent upstream Linux patch: 690fb3718a70 ("usb: dwc3: Support Synopsys USB 3.1 IP") Reviewed-

Re: [PATCH 03/11] mach-snapdragon: use 1MiB for get_page_table_size()

On 09/08/2024 01:59, Caleb Connolly wrote: From: Neil Armstrong With 14+ entries in the memory map, we need quite a bit more space for the page tables. Signed-off-by: Neil Armstrong Forgot my SoB --- arch/arm/mach-snapdragon/board.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(

[PATCH 11/11] qcom_defconfig: bump CONFIG_NR_DRAM_BANKS

Some newer boards end up with a bunch of holes in the memory map due to how Qualcomm's hypervisor and ABL work. The end result is 14+ memory regions. Bump CONFIG_NR_DRAM_BANKS to 24 so we can handle these and any future expansion easily. Yes, this is ridiculous, but there is no other way. Signed

[PATCH 10/11] soc: qcom: cmd-db: map cmd-db region

On at least SM8650 this region might not be included in the memory map. Use the new mmu_map_region() helper to map it during bind(). Signed-off-by: Caleb Connolly --- drivers/soc/qcom/cmd-db.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/soc/qcom/cmd-db.c

[PATCH 09/11] soc: qcom: cmd-db: use strncmp() instead of memcmp()

memcmp() can cause aborts on some platforms and generally seems to be the wrong approach here. Use strncmp() instead which is more correct. Signed-off-by: Caleb Connolly --- drivers/soc/qcom/cmd-db.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/soc/qcom/cmd-db.c b/

[PATCH 08/11] armv8: mmu: add a way to map additional regions

In some cases we might want to map some memory region after enabling caches. Introduce a new helper for this. Signed-off-by: Caleb Connolly --- arch/arm/cpu/armv8/cache_v8.c | 25 + arch/arm/include/asm/system.h | 10 ++ 2 files changed, 35 insertions(+) diff --g

[PATCH 07/11] mach-snapdragon: set loadaddr

This variable is used by default in some commands, set it to the same as kernel_addr_r. Signed-off-by: Caleb Connolly --- arch/arm/mach-snapdragon/board.c | 12 +++- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/arch/arm/mach-snapdragon/board.c b/arch/arm/mach-snapdragon/

[PATCH 06/11] mach-snapdragon: populate fallback FDT

Set the fdt_addr_r environment variable to a region of LMB allocated memory, and populate it by default with a copy of U-Boots FDT. This will be used for Linux if no other DT is provided. Signed-off-by: Caleb Connolly --- arch/arm/mach-snapdragon/board.c | 7 ++- 1 file changed, 6 insertions

[PATCH 05/11] mach-snapdragon: allocate fastboot buffer dynamically

We don't know at build time where a sensible place for this is, allocate it at runtime like the other variables. Signed-off-by: Caleb Connolly --- arch/arm/mach-snapdragon/board.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/arm/mach-snapdragon/board.c b/arch/arm/mach-snapdrag

[PATCH 04/11] mach-snapdragon: set serial number

In the typical case where we chainload from ABL, the serial number is available in the DT bootargs. Read it out and set the serial# environment variable so that it can be used by fastboot. Signed-off-by: Caleb Connolly --- arch/arm/mach-snapdragon/board.c | 62 +++

[PATCH 03/11] mach-snapdragon: use 1MiB for get_page_table_size()

From: Neil Armstrong With 14+ entries in the memory map, we need quite a bit more space for the page tables. Signed-off-by: Neil Armstrong --- arch/arm/mach-snapdragon/board.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-snapdragon/board.c b/arch/arm/mach-s

[PATCH 02/11] mach-snapdragon: parse memory ourselves

The generic memory parsing code in U-Boot lacks a few things that we need on Qualcomm: 1. It sets gd->ram_size and gd->ram_base to represent a single memory block. 2. setup_dest_addr() later relocates U-Boot to ram_base + ram_size, the end of that first memory block. This results in all mem

[PATCH 01/11] mach-snapdragon: refactor board_fdt_blob_setup()

If U-Boot has a DTB built in (appended to the image directly) then this was likely intentional, we should prioritise it over one provided by ABL (if there was one). Make this behaviour explicit, and panic if no valid DTB could be found anywhere. Returning an error is not useful in this case as U-B

[PATCH 00/11] mach-snapdragon: various improvements for newer boards

Supporting the newer SM8550 and SM8650 SoCs unfortunately requires a bump in complexity for us. Qualcomm changed a lot about how the memory map is handed over to the "kernel", adding many holes, not mapping certain regions, and adding regions with 0 size. The SM8650 HDK has a whopping 14 memory reg

Re: [PATCH] arm: dts: rockchip: disable "usb_host0_ohci" to make boot faster for Radxa ROCK 3A

sorry, please ignore this patch. Best regards, -- FUKAUMI Naoki Radxa Computer (Shenzhen) Co., Ltd. On 8/2/24 11:49, FUKAUMI Naoki wrote: on-board USB 2.0 hub, FE1.1s, has Transaction Translator which can handle USB 1.x devices via "usb_host0_ehci". so we can omit "usb_host0_ohci" and make boo

Re: [PULL] Pull request for u-boot-nand-20240808

6 > 09:36:46 -0600) > > are available in the Git repository at: > > git://source.denx.de:u-boot/custodians/u-boot-nand-flash.git/ > u-boot-nand-20240808 > > for you to fetch changes up to 855f9b6241407d19f01d4245456be428b5d88f52: > > spinand: bind UBI block (20

[PATCH v2 2/2] arm: dts: rockchip: turn LEDs on at boot for Radxa boards

Basically, Radxa's boards are intended to turn LEDs on at U-Boot. add `default-state = "on"` to u-boot.dtsi. Signed-off-by: FUKAUMI Naoki --- Changes in v2: - remove irrelevant contents from rk3399-rock-4c-plus-u-boot.dtsi - depend https://patchwork.ozlabs.org/project/uboot/patch/20240808221902.

[PATCH v2 1/2] configs: rockchip: enable gpio-leds driver for Radxa boards

Basically, Radxa's boards are intended to turn LEDs on at U-Boot. enable gpio-leds driver and led command. Signed-off-by: FUKAUMI Naoki --- Changes in v2: - none --- configs/radxa-cm3-io-rk3566_defconfig | 2 ++ configs/radxa-e25-rk3568_defconfig| 2 ++ configs/rock-3a-rk3568_defconfig

[PATCH] arm: dts: rockchip: fix dts for Radxa ROCK 4C+

Radxa ROCK Pi 4 series and Radxa ROCK 4C+ are not compatible. add rk3399-rock-pi-4-u-boot.dtsi contents and remove dependency of it. no functional change is intended. Fixes: 71a95e2efd30 ("arm: dts: rockchip: add Radxa ROCK 4C+") Suggested-by: Dragan Simic Signed-off-by: FUKAUMI Naoki --- arch

[PATCH 2/5] arch: arm: dts: k3-am69-r5-sk: Add missing fss range

Upstream DTS added explicit ranges to the fss node. It did not include the 32 bit memory space needed by the R5 to access OSPI. With the upstream DTS sync, OSPI boot no longer works. Adding the missing range here. It is also being added in the upstream DTS, so after the next upstream DTS sync, t

[PATCH 1/5] arch: arm: dts: k3-j784s4-r5-evm: Add missing fss range

Upstream DTS added explicit ranges to the fss node. It did not include the 32 bit memory space needed by the R5 to access OSPI. With the upstream DTS sync, OSPI boot no longer works. Adding the missing range here. It is also being added in the upstream DTS, so after the next upstream DTS sync, t

[PATCH 5/5] arch: arm: dts: k3-j721e-r5-sk: Add missing fss range

Upstream DTS added explicit ranges to the fss node. It did not include the 32 bit memory space needed by the R5 to access OSPI. With the upstream DTS sync, OSPI boot no longer works. Adding the missing range here. It is also being added in the upstream DTS, so after the next upstream DTS sync, t

[PATCH 0/5] arch: arm: dts: ti: Add missing fss range

Upstream DTS added explicit ranges to the fss node. It did not include the 32 bit memory space needed by the R5 to access OSPI. With the upstream DTS sync, OSPI boot no longer works. Adding the missing range here. It is also being added in the upstream DTS, so after the next upstream DTS sync, the

[PATCH 4/5] arch: arm: dts: k3-j721e-r5-evm: Add missing fss range

Upstream DTS added explicit ranges to the fss node. It did not include the 32 bit memory space needed by the R5 to access OSPI. With the upstream DTS sync, OSPI boot no longer works. Adding the missing range here. It is also being added in the upstream DTS, so after the next upstream DTS sync, t

[PATCH 3/5] arch: arm: dts: k3-j7200-r5-evm: Add missing fss range

Upstream DTS added explicit ranges to the fss node. It did not include the 32 bit memory space needed by the R5 to access OSPI. With the upstream DTS sync, OSPI boot no longer works. Adding the missing range here. It is also being added in the upstream DTS, so after the next upstream DTS sync, t

Re: [PATCH v2 36/39] efi: Add a test app

On 07.08.24 16:36, Simon Glass wrote: Hi Heinrich, On Tue, 6 Aug 2024 at 19:47, Heinrich Schuchardt wrote: On 06.08.24 14:58, Simon Glass wrote: Add a simple app to use for testing. This is intended to do whatever it needs to for testing purposes. For now it just prints a message and exits b

Re: [PATCH v2 06/39] bootstd: Create a function to reset USB

On 07.08.24 16:36, Simon Glass wrote: Hi Heinrich, On Tue, 6 Aug 2024 at 19:56, Heinrich Schuchardt wrote: On 06.08.24 14:58, Simon Glass wrote: Set up a function for this, since it needs to be used from multiple test files. Signed-off-by: Simon Glass --- (no changes since v1) test/bo

Re: [PATCH v2 37/39] efi: Avoid using sandbox virtio devices

On Thu, Aug 08, 2024 at 12:44:05PM -0600, Simon Glass wrote: > Hi Heinrick, Tom, > > On Tue, 6 Aug 2024 at 19:56, Tom Rini wrote: > > > > On Wed, Aug 07, 2024 at 03:47:21AM +0200, Heinrich Schuchardt wrote: > > > On 06.08.24 14:58, Simon Glass wrote: > > > > While sandbox supports virtio it canno

[PATCH v6] board: rockchip: add Radxa ROCK 3 Model C

From: Maxim Moskalets Based on rock-3a-rk3568_defconfig. Tested on v1.31 revision. Board Specifications: - Rockchip RK3566 - 1/2/4GB LPDDR4 2112MT/s - eMMC socket - uSD card slot - M.2 2230 Connector - GbE LAN with POE - 3.5mm jack with mic - HDMI 2.0, MIPI DSI/CSI - USB 3.0 Host, USB 2.0 Host/O

[PATCH v2 1/1] ata: sata_rescan must scan for block devices

A system may have multiple SATA controller. Removing the controller with the lowest sequence number before probing all SATA controllers makes no sense. In sata_rescan we remove all block devices which are children of SATA controllers. We also have to remove the bootdev devices as they will be crea

Re: [PATCH v2 37/39] efi: Avoid using sandbox virtio devices

Hi Heinrick, Tom, On Tue, 6 Aug 2024 at 19:56, Tom Rini wrote: > > On Wed, Aug 07, 2024 at 03:47:21AM +0200, Heinrich Schuchardt wrote: > > On 06.08.24 14:58, Simon Glass wrote: > > > While sandbox supports virtio it cannot support actually using the block > > > devices to read files, since there

Re: [PATCH 1/1] boot: set correct block device name in set_efi_bootdev()

Hi Heinrich, On Wed, 7 Aug 2024 at 14:52, Simon Glass wrote: > > Hi Heinrich, > > On Wed, 7 Aug 2024 at 08:39, Heinrich Schuchardt > wrote: > > > > On 07.08.24 16:36, Simon Glass wrote: > > > On Tue, 6 Aug 2024 at 18:13, Heinrich Schuchardt > > > wrote: > > >> > > >> For SATA devices the class

Re: [PATCH v8 00/23] Introduce the lwIP network stack

On Thu, Aug 08, 2024 at 06:41:02PM +0200, Jerome Forissier wrote: > > > On 8/7/24 22:44, Tom Rini wrote: > > On Wed, Aug 07, 2024 at 07:11:44PM +0200, Jerome Forissier wrote: > > > >> This is a rework of a patch series by Maxim Uvarov: "net/lwip: add lwip > >> library for the network stack" [1].

Re: [PATCH v6 00/11] efi: CapsuleUpdate: support for dynamic UUIDs

Small CI issue, I'll fix it up and resend https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/jobs/884570 On 08/08/2024 18:21, Caleb Connolly wrote: As more boards adopt support for the EFI CapsuleUpdate mechanism, there is a growing issue of being able to target updates to them proper

Re: [PATCH v8 00/23] Introduce the lwIP network stack

On 8/7/24 22:44, Tom Rini wrote: > On Wed, Aug 07, 2024 at 07:11:44PM +0200, Jerome Forissier wrote: > >> This is a rework of a patch series by Maxim Uvarov: "net/lwip: add lwip >> library for the network stack" [1]. The goal is to introduce the lwIP TCP/IP >> stack [2] [3] as an alternative to

Re: [PATCH v8 22/23] test/py: add HTTP (wget) test for the EFI loader

On Thu, Aug 08, 2024 at 03:06:05PM +0200, Jerome Forissier wrote: > > > On 8/7/24 19:57, Tom Rini wrote: > > On Wed, Aug 07, 2024 at 07:12:06PM +0200, Jerome Forissier wrote: > >> Add a test to test_efi_loader.py similar to the TFTP test but for HTTP > >> with the wget command. > >> > >> Suggeste

[PATCH v6 02/11] lib: uuid: add UUID v5 support

Add support for generating version 5 UUIDs, these are determistic and work by hashing a "namespace" UUID together with some unique data. One intended usecase is to allow for dynamically generate payload UUIDs for UEFI capsule updates, so that supported boards can have their own UUIDs without needin

[PATCH v2 3/3] arm64: unwind stack on exception

We already build arm64 images with frame pointers. Let's finally make use of them in tandem with the new symbol lookup support by unwinding the stack when an exception occurs, producing a backtrace similar to those emitted by Linux. In addition, introduce a dedicated unwind_stack() function which

[PATCH v6 01/11] efi: define struct efi_guid

This let's us forward declare efi_guid_t in the UUID code without pulling in efi.h Reviewed-by: Ilias Apalodimas Signed-off-by: Caleb Connolly --- include/efi.h | 2 +- tools/eficapsule.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/include/efi.h b/include/efi.h i

[PATCH v2 0/3] ARM64: add symbol name lookup and print a backtrace on exception

U-Boot already emits frame pointers on ARM64, but lacks the code to parse them, as well as a mechanism for looking up symbol names at runtime. There was some (seemingly?) leftover code for symbols lookups in common/kallsyms.c and associated parts in the makefile, however it appears to be entirely

[PATCH v6 06/11] lib: uuid: supporting building as part of host tools

Adjust the UUID library code so that it can be compiled as part of a host tool. This removes the one redundant log_debug() call, as well as the incorrectly defined LOG_CATEGORY. In general this is a fairly trivial change, just adjusting includes and disabling list_guid. This will be used by a ne

[PATCH v6 10/11] test: lib/uuid: add unit tests for dynamic UUIDs

Add some basic unit tests to validate that the UUID generation behaves as expected. This matches the implementation in efi_loader for sandbox and a Qualcomm board and should catch any regressions. Acked-by: Ilias Apalodimas Signed-off-by: Caleb Connolly --- test/lib/uuid.c | 82

[PATCH] cmd: add a fetch utility

While U-Boot does a pretty good job at printing information at startup about what hardware it's running on, it can be hard to take pretty pictures of this to show off on the internet (by far the most important aspect of porting a device in 2024!). Add a small utility "ufetch" for displaying some i

[PATCH v6 00/11] efi: CapsuleUpdate: support for dynamic UUIDs

As more boards adopt support for the EFI CapsuleUpdate mechanism, there is a growing issue of being able to target updates to them properly. The current mechanism of hardcoding UUIDs for each board at compile time is unsustainable, and maintaining lists of GUIDs is similarly cumbersome. In this se

[PATCH v6 04/11] doc: uefi: document dynamic UUID generation

Document how platforms can generate GUIDs at runtime rather than maintaining a list of UUIDs per-board. Reviewed-by: Ilias Apalodimas Signed-off-by: Caleb Connolly --- doc/develop/uefi/uefi.rst | 27 +++ 1 file changed, 27 insertions(+) diff --git a/doc/develop/uefi/uef

[PATCH v6 03/11] efi: add a helper to generate dynamic UUIDs

Introduce a new helper efi_capsule_update_info_gen_ids() which populates the capsule update fw images image_type_id field. This allows for determinstic UUIDs to be used that can scale to a large number of different boards and board variants without the need to maintain a big list. We call this fro

[PATCH v6 08/11] tools: mkeficapsule: use u-boot UUID library

Replace the use of libuuid with U-Boot's own UUID library. This prepares us to add support for generating v5 GUIDs. Signed-off-by: Caleb Connolly --- tools/Makefile | 8 tools/mkeficapsule.c | 53 ++-- 2 files changed, 10 insertions

[PATCH v6 11/11] test: lib/uuid: add tests for UUID version/variant bits

Add a test to check the version/variant bits of v4 and v5 UUIDs. Signed-off-by: Caleb Connolly --- test/lib/uuid.c | 36 1 file changed, 36 insertions(+) diff --git a/test/lib/uuid.c b/test/lib/uuid.c index 2c6cfd42ddc3..63d36e120623 100644 --- a/test/lib/uu

[PATCH v2 2/3] add support for symbol lookups

This is mostly a port of the Xen hypervisor implementation. The U-Boot binary is built as normal, then its symbol table is fed into tools/symbols to generate an optimised lookup table. U-Boot is rebuilt with the symbol table and handling code in lib/symbols.c. Based on code from Xen at c20850540

[PATCH v6 09/11] tools: mkeficapsule: support generating dynamic GUIDs

Add support for generating GUIDs that match those generated internally by U-Boot for capsule update fw_images when using dynamic UUIDs. Dynamic UUIDs in U-Boot work by taking a namespace UUID and hashing it with the board compatible and fw_image name. This feature just provides a way to determine

Re: [PATCH v8 22/23] test/py: add HTTP (wget) test for the EFI loader

On 8/8/24 18:20, Tom Rini wrote: > On Thu, Aug 08, 2024 at 03:06:05PM +0200, Jerome Forissier wrote: >> >> >> On 8/7/24 19:57, Tom Rini wrote: >>> On Wed, Aug 07, 2024 at 07:12:06PM +0200, Jerome Forissier wrote: Add a test to test_efi_loader.py similar to the TFTP test but for HTTP wi

Re: [PATCH v8 22/23] test/py: add HTTP (wget) test for the EFI loader

On 8/8/24 17:52, Tom Rini wrote: > On Thu, Aug 08, 2024 at 03:06:05PM +0200, Jerome Forissier wrote: >> >> >> On 8/7/24 19:57, Tom Rini wrote: >>> On Wed, Aug 07, 2024 at 07:12:06PM +0200, Jerome Forissier wrote: Add a test to test_efi_loader.py similar to the TFTP test but for HTTP wi

[PATCH v6 05/11] sandbox: switch to dynamic UUIDs

Migrate sandbox over to generating it's capsule update image GUIDs dynamically from the namespace and board/image info. Update the reference and tests to use the new GUIDs. Acked-by: Ilias Apalodimas Signed-off-by: Caleb Connolly --- board/sandbox/sandbox.c | 16

[PATCH v6 07/11] include: export uuid.h

Move this header to include/u-boot/ so that it can be used by external tools. Reviewed-by: Ilias Apalodimas Signed-off-by: Caleb Connolly --- arch/arm/mach-rockchip/board.c | 2 +- board/cobra5272/flash.c| 2 +- board/gardena/smart-gateway-mt7688/board.c | 2 +-

Re: [PATCH v8 22/23] test/py: add HTTP (wget) test for the EFI loader

On Thu, Aug 08, 2024 at 03:06:05PM +0200, Jerome Forissier wrote: > > > On 8/7/24 19:57, Tom Rini wrote: > > On Wed, Aug 07, 2024 at 07:12:06PM +0200, Jerome Forissier wrote: > >> Add a test to test_efi_loader.py similar to the TFTP test but for HTTP > >> with the wget command. > >> > >> Suggeste

[PATCH v2 1/3] drop unused kallsyms support

There was some very old code floating around for decoding symbols, it's incomplete and is never built. Remove it so we can add a new implementation. Reviewed-by: Tom Rini Reviewed-by: Ilias Apalodimas Signed-off-by: Caleb Connolly --- Makefile| 11 --- common/Makefile |

Re: [PATCH V8 2/7] doc: ti: k3: Add TIFS Stub documentation

On Mon, Aug 05, 2024 at 07:59:32PM +0530, Dhruva Gole wrote: > * Add documentation to briefly explain the role of TIFS Stub in relevant > K3 SoC's. > * Shed light on why TIFS Stub isn't package with the DM firmware itself. > * Modify the platform docs wherever the TIFS Stub documentation applies.

Re: [PATCH] cmd: sf: prevent overwriting the reserved memory

On Thu, Aug 08, 2024 at 01:18:44PM +0200, Michal Simek wrote: > > > On 8/8/24 08:22, Sughosh Ganu wrote: > > On Thu, 8 Aug 2024 at 11:05, Michal Simek wrote: > > > > > > > > > > > > On 8/7/24 23:12, Tom Rini wrote: > > > > On Tue, Aug 06, 2024 at 05:37:00PM +0530, Prasad Kummari wrote: > > >

Re: [PATCH v3 0/7] FUSB302 USB-C controller support

On 08.08.24 16:34, Sören Moch wrote: On 08.08.24 15:58, Soeren Moch wrote: On 02.08.24 19:59, Sebastian Reichel wrote: 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 connec

Re: Please pull u-boot-i2c

On Thu, Aug 08, 2024 at 04:06:44PM +0200, Heiko Schocher wrote: > Hello Tom, > > On 08.08.24 15:58, Tom Rini wrote: > > On Thu, Aug 08, 2024 at 10:42:47AM +0200, Heiko Schocher wrote: > > > > > Hello Tom, > > > > > > please pull from u-boot-i2c: > > > > > > The following changes since commit >

Re: [PATCH 06/17] acpi: Add define for GTDT

On Sat, Jul 27, 2024 at 12:21 AM Patrick Rudolph wrote: > > Add the interrupt flag used in ACPI GTDT table as define. > > Signed-off-by: Patrick Rudolph > Cc: Simon Glass > --- > include/acpi/acpi_table.h | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/include/acpi/acpi_table.h b/inc

Re: [PATCH 05/17] serial: serial_pl01x: Implement .getinfo() for PL01

On Sat, Jul 27, 2024 at 12:21 AM Patrick Rudolph wrote: > > From: Maximilian Brune > > When ACPI is enabled on arm it will use the getinfo function to fill > the SPCR ACPI table. > > Signed-off-by: Maximilian Brune > Cc: Simon Glass > Cc: Tom Rini Reviewed-by: Moritz Fischer > --- > boot/bo

Re: [PATCH v3 0/7] FUSB302 USB-C controller support

On 08.08.24 15:58, Soeren Moch wrote: On 02.08.24 19:59, Sebastian Reichel wrote: 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 contr

Re: [PATCH 23/40] lmb: add a flags parameter to the API's

Hi Sughosh, On Wed, 7 Aug 2024 at 00:32, Sughosh Ganu wrote: > > On Wed, 7 Aug 2024 at 03:21, Simon Glass wrote: > > > > Hi Sughosh, > > > > On Mon, 5 Aug 2024 at 05:55, Sughosh Ganu wrote: > > > > > > On Mon, 29 Jul 2024 at 20:56, Simon Glass wrote: > > > > > > > > Hi Sughosh, > > > > > > > >

Re: Selecting serial device for console

Hi Mark, On Tue, 6 Aug 2024 at 16:33, Mark Kettenis wrote: > > > From: Simon Glass > > Date: Tue, 6 Aug 2024 15:50:44 -0600 > > Hi Simon, > > > Hi Fiona, > > > > On Thu, 1 Aug 2024 at 08:07, Fiona Klute wrote: > > > > > > Hi everyone, > > > > > > how can I configure which of the available seria

Re: [Binman] Question regarding SPL symbol offsets generation

Hi Lukasz, On Thu, 8 Aug 2024 at 03:06, Lukasz Majewski wrote: > > Dear Community > > I'd like to ask about one issue with generation of symbol offsets in > binman [1]. > > In my case the CONFIG_FSPI_CONF_HEADER is defined. > > Problem is with generated symbols [2] to point into > ddr-1d-imem-fw/

Re: [PATCH] cmd: sf: prevent overwriting the reserved memory

Hi Michal, On Wed, 7 Aug 2024 at 23:31, Michal Simek wrote: > > > > On 8/7/24 16:36, Simon Glass wrote: > > Hi Prasad, > > > > On Tue, 6 Aug 2024 at 23:05, Kummari, Prasad wrote: > >> > >> Hi Glass, > >> > >>> -Original Message- > >>> From: Simon Glass > >>> Sent: Wednesday, August 7, 2

  1   2   >