Re: [U-Boot, v6, 1/1] misc: fs_loader: Add request_firmware_into_buf_via_script() for flexible firmware loading via U-Boot script

On Sun, 17 Aug 2025 23:02:03 +0800, Lucien.Jheng wrote: > This commit introduces a new API, > request_firmware_into_buf_via_script(), to the fs_loader framework. > This function allows firmware to be loaded into memory using > a user-defined U-Boot script, providing greater flexibility for > firmw

Re: [U-Boot, v6, 1/1] misc: fs_loader: Add request_firmware_into_buf_via_script() for flexible firmware loading via U-Boot script

Marek Vasut 於 2025/8/18 上午 07:00 寫道: On 8/17/25 5:02 PM, Lucien.Jheng wrote: This commit introduces a new API, request_firmware_into_buf_via_script(), to the fs_loader framework. This function allows firmware to be loaded into memory using a user-defined U-Boot script, providing greater flexib

Re: [U-Boot, v5, 1/1] misc: fs_loader: Add request_firmware_into_buf_via_script() for flexible firmware loading via U-Boot script

Marek Vasut 於 2025/8/17 下午 08:27 寫道: On 8/14/25 5:12 PM, Lucien.Jheng wrote: Hi, +    if (size > max_size) { +    log_err("Loaded firmware size 0x%lx exceeded maximum allowed size 0x%lx.\n", +    size, max_size); +    return -E2BIG; +    } + +    memcpy(*buf, (void *)addr,

Re: [U-Boot, v6, 1/1] misc: fs_loader: Add request_firmware_into_buf_via_script() for flexible firmware loading via U-Boot script

On 8/17/25 5:02 PM, Lucien.Jheng wrote: This commit introduces a new API, request_firmware_into_buf_via_script(), to the fs_loader framework. This function allows firmware to be loaded into memory using a user-defined U-Boot script, providing greater flexibility for firmware loading scenarios tha

Re: [U-Boot, v5, 1/1] misc: fs_loader: Add request_firmware_into_buf_via_script() for flexible firmware loading via U-Boot script

On 8/14/25 5:12 PM, Lucien.Jheng wrote: Hi, + if (size > max_size) { + log_err("Loaded firmware size 0x%lx exceeded maximum allowed size 0x%lx.\n", + size, max_size); + return -E2BIG; + } + + memcpy(*buf, (void *)addr, min(siz

Re: [U-Boot, v4, 1/1] misc: fs_loader: Add request_firmware_into_buf_via_script() for flexible firmware loading via U-Boot script

On 8/4/25 5:07 PM, Lucien.Jheng wrote: +/** + * request_firmware_into_buf_via_script() - + * Load firmware using a U-Boot script and copy to buffer + * @buf: Pointer to a pointer where the firmware buffer will be stored. + * @max_size: Maximum allowed size for the firmware to be loaded. + * @scr

Re: U-Boot support for wolfTPM and firmware update for SLB9672/SLB9673

Hi Ilias, Sounds good, I will keep them in cmd/wolftpm.c. I guess Simon can probably answer the other question the best. He had asked if I could "put the driver code into drivers/ with just the command code in cmd/" so I am just trying to get clarity on what driver code he is specifically referrin

Re: U-Boot support for wolfTPM and firmware update for SLB9672/SLB9673

Hi Aidan, On Sat, 2 Aug 2025 at 01:59, Aidan Garske wrote: > > Hi Simon and Ilias, > > Thank you for the great feedback. Currently I am working in the refactor you > suggested and I wanted to ask a question about some of your comments. > > 1. What exactly is the "driver code" you are referring

Re: [U-Boot, v3, 1/1] misc: fs_loader: Add request_firmware_into_buf_via_script() for flexible firmware loading via U-Boot script

Marek Vasut 於 2025/7/30 上午 02:07 寫道: On 7/29/25 4:51 PM, Lucien.Jheng wrote: [...] +int request_firmware_into_buf_via_script(void **buf, size_t max_size, +  const char *script_name) +{ [...] +    *buf = (void *)memdup((void *)addr, size); +    if (!*bu

Re: U-Boot support for wolfTPM and firmware update for SLB9672/SLB9673

Hi Simon and Ilias, Thank you for the great feedback. Currently I am working in the refactor you suggested and I wanted to ask a question about some of your comments. 1. What exactly is the "driver code" you are referring to in this case? 2. Do you want me to separate out our helper functions int

Re: U-Boot support for wolfTPM and firmware update for SLB9672/SLB9673

Hi Simon, Thank you for the great feedback. Currently I am working in the refactor you suggested and I wanted to ask a question about some of your comments. 1. What exactly is the "driver code" you are referring to in this case? 2. Do you want me to separate out our helper functions into a `cmd/w

Re: [U-Boot, v3, 1/1] misc: fs_loader: Add request_firmware_into_buf_via_script() for flexible firmware loading via U-Boot script

On 7/29/25 4:51 PM, Lucien.Jheng wrote: [...] +int request_firmware_into_buf_via_script(void **buf, size_t max_size, + const char *script_name) +{ [...] + *buf = (void *)memdup((void *)addr, size); + if (!*buf) { + log_err("Fail

Re: [U-Boot, v2, 1/1] misc: fs_loader: Add request_firmware_into_buf_via_script() for flexible firmware loading via U-Boot script

On 7/28/25 8:08 PM, Frank Wunderlich wrote: Am 28. Juli 2025 18:34:01 MESZ schrieb "Lucien.Jheng" : Marek Vasut 於 2025/7/27 下午 10:46 寫道: On 7/27/25 4:16 PM, Lucien.Jheng wrote: This commit introduces a new API, request_firmware_into_buf_via_script(), to the fs_loader framework. This function

Re: [U-Boot, v2, 1/1] misc: fs_loader: Add request_firmware_into_buf_via_script() for flexible firmware loading via U-Boot script

Am 28. Juli 2025 18:34:01 MESZ schrieb "Lucien.Jheng" : > >Marek Vasut 於 2025/7/27 下午 10:46 寫道: >> On 7/27/25 4:16 PM, Lucien.Jheng wrote: >>> This commit introduces a new API, request_firmware_into_buf_via_script(), >>> to the fs_loader framework. >>> This function allows firmware to be loaded int

Re: [U-Boot, v2, 1/1] misc: fs_loader: Add request_firmware_into_buf_via_script() for flexible firmware loading via U-Boot script

Marek Vasut 於 2025/7/27 下午 10:46 寫道: On 7/27/25 4:16 PM, Lucien.Jheng wrote: This commit introduces a new API, request_firmware_into_buf_via_script(), to the fs_loader framework. This function allows firmware to be loaded into memory using a user-defined U-Boot script, providing greater flexi

Re: [u-boot-test-hooks PATCH] travis-ci: Wire MB-V targets for CI

On Tue, 22 Jul 2025 12:51:45 +0200, Michal Simek wrote: > When QEMU v10 upgrade happens MB-V targets should be wired to add them to > CI that's why add configuration for it. > > Applied to u-boot/u-boot-test-hooks.git/master, thanks! [1/1] travis-ci: Wire MB-V targets for CI commit: 6e69

Re: [u-boot-test-hooks PATCH] travis-ci: Wire MB-V targets for CI

On 7/22/25 22:08, Tom Rini wrote: On Tue, Jul 22, 2025 at 12:51:45PM +0200, Michal Simek wrote: When QEMU v10 upgrade happens MB-V targets should be wired to add them to CI that's why add configuration for it. Signed-off-by: Michal Simek Reviewed-by: Tom Rini Thanks. Can you please m

Re: [U-Boot, v2, 1/1] misc: fs_loader: Add request_firmware_into_buf_via_script() for flexible firmware loading via U-Boot script

On 7/27/25 4:16 PM, Lucien.Jheng wrote: This commit introduces a new API, request_firmware_into_buf_via_script(), to the fs_loader framework. This function allows firmware to be loaded into memory using a user-defined U-Boot script, providing greater flexibility for firmware loading scenarios tha

Re: [u-boot-test-hooks PATCH] travis-ci: Wire MB-V targets for CI

On Tue, Jul 22, 2025 at 12:51:45PM +0200, Michal Simek wrote: > When QEMU v10 upgrade happens MB-V targets should be wired to add them to > CI that's why add configuration for it. > > Signed-off-by: Michal Simek Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature

Re: [U-Boot, v1, 1/1] misc: fs_loader: Add request_firmware_into_buf_via_env API for environment-based firmware loading

Am 21. Juli 2025 17:33:48 MESZ schrieb Tom Rini : >On Sun, Jul 20, 2025 at 10:47:50PM +0200, Marek Vasut wrote: >> On 7/20/25 5:04 PM, Lucien.Jheng wrote: >> > This commit adds request_firmware_into_buf_via_env() to the fs_loader >> > driver, >> > enabling firmware loading into a buffer >> > using

Re: [U-Boot, v1, 1/1] misc: fs_loader: Add request_firmware_into_buf_via_env API for environment-based firmware loading

On Sun, Jul 20, 2025 at 10:47:50PM +0200, Marek Vasut wrote: > On 7/20/25 5:04 PM, Lucien.Jheng wrote: > > This commit adds request_firmware_into_buf_via_env() to the fs_loader > > driver, > > enabling firmware loading into a buffer > > using environment variables for path and size. > > It support

Re: [U-Boot, v1, 1/1] misc: fs_loader: Add request_firmware_into_buf_via_env API for environment-based firmware loading

On 7/20/25 5:04 PM, Lucien.Jheng wrote: This commit adds request_firmware_into_buf_via_env() to the fs_loader driver, enabling firmware loading into a buffer using environment variables for path and size. It supports multiple entries via indexed variable names (e.g., "fw_dir0", "fw_size0"). This

Re: [U-Boot, v1, 1/1] misc: fs_loader: Add request_firmware_into_buf_via_env API for environment-based firmware loading

On 7/20/25 5:31 PM, Heinrich Schuchardt wrote: Am 20. Juli 2025 17:04:04 MESZ schrieb "Lucien.Jheng" : This commit adds request_firmware_into_buf_via_env() to the fs_loader driver, enabling firmware loading into a buffer using environment variables for path and size. It supports multiple entries

Re: [U-Boot, v1, 1/1] misc: fs_loader: Add request_firmware_into_buf_via_env API for environment-based firmware loading

Am 20. Juli 2025 17:04:04 MESZ schrieb "Lucien.Jheng" : >This commit adds request_firmware_into_buf_via_env() to the fs_loader driver, >enabling firmware loading into a buffer >using environment variables for path and size. >It supports multiple entries via indexed variable names >(e.g., "fw_dir0",

RE: u-boot corruption from EFI CAAM RNG request

> Hi Anthony, > > On Mon, Jul 14, 2025 at 10:0 AM Anthony Pighin (Nokia) > wrote: > > > > > u-boot is being corrupted following a Linux EFI callback to > > > get_rng(). One of the many footprints is a corruption of the EFI protocols > linked list. > > Which SoC do you use? I first noticed this

Re: u-boot corruption from EFI CAAM RNG request

Hi Anthony, On Mon, Jul 14, 2025 at 10:04 AM Anthony Pighin (Nokia) wrote: > > > u-boot is being corrupted following a Linux EFI callback to get_rng(). One > > of > > the many footprints is a corruption of the EFI protocols linked list. Which SoC do you use? > Here is a proposed fix. The caam_

RE: u-boot corruption from EFI CAAM RNG request

> u-boot is being corrupted following a Linux EFI callback to get_rng(). One of > the many footprints is a corruption of the EFI protocols linked list. > > Turns out that a request for >16 bytes of random data is broken into smaller > requests. > Those requests are fed in a loop to the CAAM RNG, w

Re: [U-Boot, v2, 1/1] net: phy: Add the Airoha EN8811H PHY driver

Marek Vasut 於 2025/6/30 上午 06:49 寫道: On 6/29/25 6:10 PM, Lucien.Jheng wrote: Hi, I'm sorry for my abysmally slow response. Thank you very much for your reply and sharing; I've learned a lot. +config PHY_AIROHA_FW_IN_MMC +    bool "Airoha firmware in MMC partition" +    help +  Airoha P

Re: [U-Boot, v2, 1/1] net: phy: Add the Airoha EN8811H PHY driver

On 6/29/25 6:10 PM, Lucien.Jheng wrote: Hi, I'm sorry for my abysmally slow response. +config PHY_AIROHA_FW_IN_MMC +    bool "Airoha firmware in MMC partition" +    help +  Airoha PHYs use firmware which can be loaded automatically +  from storage directly attached to the PHY, and then

Re: [U-Boot, v2, 1/1] net: phy: Add the Airoha EN8811H PHY driver

Marek Vasut 於 2025/6/29 下午 10:31 寫道: On 6/15/25 3:12 PM, Lucien.Jheng wrote: Add the driver for the Airoha EN8811H 2.5 Gigabit PHY. The PHY supports 100/1000/2500 Mbps with auto negotiation only. The driver uses two firmware files, for which updated versions are added to linux-firmware alre

Re: [U-Boot, v2, 1/1] net: phy: Add the Airoha EN8811H PHY driver

On 6/15/25 3:12 PM, Lucien.Jheng wrote: Add the driver for the Airoha EN8811H 2.5 Gigabit PHY. The PHY supports 100/1000/2500 Mbps with auto negotiation only. The driver uses two firmware files, for which updated versions are added to linux-firmware already. Locating the AIROHA FW within the fi

Re: [U-Boot, v1, 1/1] net: phy: Add the Airoha EN8811H PHY driver

On 5/11/25 7:14 AM, Lucien.Jheng wrote: Add the driver for the Airoha EN8811H 2.5 Gigabit PHY. The PHY supports 100/1000/2500 Mbps with auto negotiation only. The driver uses two firmware files, for which updated versions are added to linux-firmware already. Locating the AIROHA FW within the fi

Re: U-Boot support for wolfTPM and firmware update for SLB9672/SLB9673

Hi Ilias, Thank you for the reply. I totally understand about being busy! There is nothing specific to discuss at this point. I’ll reach out again soon with the proposed u-boot wolfTPM patches. Thanks, David Garske Software Engineer, wolfSSL +1 (530) 409-2990 https://www.wolfssl.com

Re: U-Boot support for wolfTPM and firmware update for SLB9672/SLB9673

Hi David, On Fri, 30 May 2025 at 22:46, David Garske wrote: > > Hi Ilias, > > Thank you for the reply. I totally understand about being busy! There is > nothing specific to discuss at this point. I’ll reach out again soon with the > proposed u-boot wolfTPM patches. Thanks, the best advice I ca

Re: U-Boot support for wolfTPM and firmware update for SLB9672/SLB9673

Hi David, On Wed, 21 May 2025 at 20:12, David Garske wrote: > > Hi Ilias, > > Thank you! It’s a pleasure to meet you! I’m the author and maintainer or > wolfTPM. > > Perhaps it would be useful to meet and chat for a bit? Are you free next week > May 28th at 7:30 AM PT? > > I loved the feedback

Re: U-Boot support for wolfTPM and firmware update for SLB9672/SLB9673

Hi Ilias, Thank you! It’s a pleasure to meet you! I’m the author and maintainer or wolfTPM. Perhaps it would be useful to meet and chat for a bit? Are you free next week May 28th at 7:30 AM PT? I loved the feedback from Simon Glass and we will be implementing those and suggesting a new patch

Re: U-Boot support for wolfTPM and firmware update for SLB9672/SLB9673

On Fri, 9 May 2025 at 18:43, David Garske wrote: > > Hi Ilias, > > Thank you for the quick reply. I am happy that you will consider wolfTPM as a > submodule. We have 100’s of commercial customers and it is very actively > maintained. In fact we will continue to provide direct maintenance for any

Re: u-boot on x86

Hi Michael, On Mon, 12 May 2025 at 15:59, Michael wrote: > > Hi Simon, > > when i execute the 'acpi' command i can see the tables. > I've also tried to enable the CONFIG_SMP Option - without any changes. > When using grub i can dump the tables - With u-boot i'm getting "Could not > get acpi tabl

Re: u-boot on x86

Hi Michael, On Thu, 8 May 2025 at 14:51, Michael wrote: > > Hello!, > > i'm currently working on a project that could use several architectures > (arm / x86). > To have a common base for all systems, i want to use u-boot as unified > bootloader for both platforms. > At the moment i try to get u-b

Re: U-Boot support for wolfTPM and firmware update for SLB9672/SLB9673

Hi David, On Thu, 8 May 2025 at 00:41, David Garske wrote: > > Hi Denx, > > We at wolfSSL have developed a port for wolfTPM in U-Boot. The patch allows > using the current built-in TPM 2.0 support or switching to wolfTPM via > CONFIG_TPM_WOLF=y. It also supports TPM 2.0 firmware update for the

Re: U-Boot support for wolfTPM and firmware update for SLB9672/SLB9673

Hi David > Hi Denx, > > We at wolfSSL have developed a port for wolfTPM in U-Boot. The patch allows > using the current built-in TPM 2.0 support or switching to wolfTPM via > CONFIG_TPM_WOLF=y. It also supports TPM 2.0 firmware update for the Infineon > SLB9672 and SLB9673. > > I think there is

Re: U-Boot support for wolfTPM and firmware update for SLB9672/SLB9673

Hi Ilias, Thank you for the quick reply. I am happy that you will consider wolfTPM as a submodule. We have 100’s of commercial customers and it is very actively maintained. In fact we will continue to provide direct maintenance for any u-boot issues that come up using wolfTPM. Also we’ve done s

Re: [u-boot-test-hooks PATCH 1/1] travis-ci: qemu-riscv64_na: add a second network interface

On Tue, 15 Apr 2025 11:11:59 +0200, Heinrich Schuchardt wrote: > U-Boot allows to have multiple network interfaces and switching between > these. This functionality cannot be tested if QEMU only emulates a single > NIC. > > Provide a QEMU configuration with multiple network interfaces. > > > [.

Re: [u-boot-test-hooks PATCH 1/2] travis-ci: Add qemu_arm/64_spl board

On Wed, 16 Apr 2025 17:31:31 -0600, Simon Glass wrote: > These are similar to the existing qemu_arm/64 targets, except that the > 'bios' is image.bin (containing both SPL and U-Boot) rather than in > u-boot.bin > > Applied to u-boot/u-boot-test-hooks.git/master, thanks! [1/2] travis-ci: Add qe

Re: [u-boot-test-hooks][PATCH] Add support for FVP emulator and fiptool

On Tue, 15 Apr 2025 15:50:34 -0600, Tom Rini wrote: > This adds support for the vexpress_fvp platforms. In order to do that we > need to add support for calling fiptool to update an existing "fip" file > with our U-Boot build. We also need to support launching the FVP > emulator itself. This is a

Re: [U-Boot, v1, 1/1] net: phy: air_en8811h: load the PHY firmware from filesystem on block device instead

Deal maintainers Considering system-level factors, this commit will not be submitted at this time. Thank you. Lucien.Jheng 於 2025/4/19 下午 05:43 寫道: Locating the AIROHA FW within the filesystem at the designated partition and path will trigger its automatic loading and writing to the PHY via

Re: [u-boot-test-hooks][PATCH] Add support for FVP emulator and fiptool

On 15/04/2025 22:50, Tom Rini wrote: This adds support for the vexpress_fvp platforms. In order to do that we need to add support for calling fiptool to update an existing "fip" file with our U-Boot build. We also need to support launching the FVP emulator itself. This is a little tricky in that

Re: [u-boot-test-hooks PATCH 1/1] travis-ci: qemu-riscv64_na: add a second network interface

On Tue, 15 Apr 2025 at 12:12, Heinrich Schuchardt wrote: > > U-Boot allows to have multiple network interfaces and switching between > these. This functionality cannot be tested if QEMU only emulates a single > NIC. > > Provide a QEMU configuration with multiple network interfaces. > > Signed-off-

Re: [U-Boot][PATCH v1] cmd/fpga: use config node for loadmk

HI, pá 21. 2. 2025 v 12:04 odesílatel Ibai Erkiaga napsal: > > Current implementation requires to provide the name of the FPGA image > within the FIT image. As the configuration node is mandatory according > to the spec and includes an optional property "fpga" to define the > bitstream image, use

Re: U-Boot interferes with initrd binary — Revert "efi: Correct smbios-table installation" ?

Hi, On Sun, 6 Apr 2025 at 08:51, Christian Kohlschütter wrote: > > On 4. Apr 2025, at 18:21, neil.armstr...@linaro.org wrote: > > > > Hi Christian > > > ... > > > > could you test: > > > > ==><== > > diff --git a/drivers/net/dwmac_meson8b.c b/drivers/net/dwmac_meso

Re: U-Boot interferes with initrd binary — Revert "efi: Correct smbios-table installation" ?

On 4. Apr 2025, at 18:21, neil.armstr...@linaro.org wrote: > > Hi Christian > ... > > could you test: > > ==><== > diff --git a/drivers/net/dwmac_meson8b.c b/drivers/net/dwmac_meson8b.c > index fde4aabbace..bf9c5e8f349 100644 > --- a/drivers/net/dwmac_meson8b.c >

Re: U-Boot interferes with initrd binary — Revert "efi: Correct smbios-table installation" ?

On 31/03/2025 18:31, Christian Kohlschütter wrote: Whoa! Good eyes, Michael! What is my Fritzbox doing to my initrd, and why does reverting the commit fix it? FWIW, I also have a capture with an ethernet frame from another device on my network (ARP, ethertype 0x0806), so this is probably the

Re: U-Boot interferes with initrd binary — Revert "efi: Correct smbios-table installation" ?

Hi Christian, On Fri, 4 Apr 2025 at 08:18, Christian Kohlschütter wrote: > > +Tom Rini (actually adding Tom to the conversation) > > > On 3. Apr 2025, at 19:54, Simon Glass wrote: > > > > +Tom Rini in case this affects the release > > > > Hi Christian, > > > > On Fri, 4 Apr 2025 at 01:46, Christ

Re: U-Boot interferes with initrd binary — Revert "efi: Correct smbios-table installation" ?

Hi Simon, > On 1. Apr 2025, at 17:51, Simon Glass wrote: >> >> but I don't know precisely what these various functions are supposed to >> do, and I can't find any path that leads from any of these to eth_halt(). >> >> Is it possible that U-Boot is failing to call eth_halt() in response to >> Ex

Re: U-Boot interferes with initrd binary — Revert "efi: Correct smbios-table installation" ?

Hi Christian On 04/04/2025 00:41, Simon Glass wrote: Hi Christian, On Fri, 4 Apr 2025 at 08:18, Christian Kohlschütter wrote: +Tom Rini (actually adding Tom to the conversation) On 3. Apr 2025, at 19:54, Simon Glass wrote: +Tom Rini in case this affects the release Hi Christian, On Fri

Re: U-Boot interferes with initrd binary — Revert "efi: Correct smbios-table installation" ?

Hi, On 31/03/2025 18:49, Christian Kohlschütter wrote: Hi all, After upgrading some rather old U-Boot/IPXE setup on two aarch64 boards (Amlogic S922X-based ODROID N2+ and RK3399-based NanoPi R4S), I noticed strange errors in the initrd phase of my Linux kernel — usually something like "Illega

Re: U-Boot interferes with initrd binary — Revert "efi: Correct smbios-table installation" ?

On 03/04/2025 23:41, Simon Glass wrote: On Fri, 4 Apr 2025 at 08:18, Christian Kohlschütter wrote: On 3. Apr 2025, at 19:54, Simon Glass wrote: 4. DMA traffic could then write over the malloc() region I'm not seeing where the Ethernet device's stop() is called. The dwmac_meson8b driver does

Re: U-Boot interferes with initrd binary — Revert "efi: Correct smbios-table installation" ?

On 03/04/2025 20:18, Christian Kohlschütter wrote: +Tom Rini (actually adding Tom to the conversation) 3. When the device is removed, the struct is freed, meaning that a future malloc() can use that same space. Yes, that sounds plausible. How can such allocations be prevented? I assume U-Boot

Re: U-Boot interferes with initrd binary — Revert "efi: Correct smbios-table installation" ?

+Tom Rini (actually adding Tom to the conversation) > On 3. Apr 2025, at 19:54, Simon Glass wrote: > > +Tom Rini in case this affects the release > > Hi Christian, > > On Fri, 4 Apr 2025 at 01:46, Christian Kohlschütter > wrote: >> >> Hi Simon, >> >>> On 1. Apr 2025, at 17:51, Simon Glass

Re: U-Boot interferes with initrd binary — Revert "efi: Correct smbios-table installation" ?

+Tom Rini in case this affects the release Hi Christian, On Fri, 4 Apr 2025 at 01:46, Christian Kohlschütter wrote: > > Hi Simon, > > > On 1. Apr 2025, at 17:51, Simon Glass wrote: > >> > >> but I don't know precisely what these various functions are supposed to > >> do, and I can't find any pa

Re: U-Boot interferes with initrd binary — Revert "efi: Correct smbios-table installation" ?

On 31. Mar 2025, at 19:15, Michael Brown wrote: > > On 31/03/2025 17:49, Christian Kohlschütter wrote: >> # hexdump /.argh >> 000 >> * >> 0044100 15dc f9c8 6f16 e188 >> 0044110 00a0 52b0 a01c 6d59 >> 0044120

Re: U-Boot interferes with initrd binary — Revert "efi: Correct smbios-table installation" ?

Hi Michael, On Tue, 1 Apr 2025 at 23:22, Michael Brown wrote: > > On 31/03/2025 18:31, Christian Kohlschütter wrote: > > Whoa! Good eyes, Michael! > > > > What is my Fritzbox doing to my initrd, and why does reverting the commit > > fix it? > > > > FWIW, I also have a capture with an ethernet fr

Re: U-Boot interferes with initrd binary — Revert "efi: Correct smbios-table installation" ?

On 31/03/2025 18:31, Christian Kohlschütter wrote: Whoa! Good eyes, Michael! What is my Fritzbox doing to my initrd, and why does reverting the commit fix it? FWIW, I also have a capture with an ethernet frame from another device on my network (ARP, ethertype 0x0806), so this is probably the

Re: U-Boot interferes with initrd binary — Revert "efi: Correct smbios-table installation" ?

On 31/03/2025 17:49, Christian Kohlschütter wrote: # hexdump /.argh 000 * 0044100 15dc f9c8 6f16 e188 0044110 00a0 52b0 a01c 6d59 0044120 0044130 00

Re: [U-Boot] [PATCH 13/15] x86: Increase the size of the phys_size_t and phys_addr_t types

Re: [u-boot-test-hooks PATCH 1/2] labgrid-sjg: Add kea lab

On Fri, 21 Feb 2025 13:43:01 -0700, Simon Glass wrote: > Add the current state of the kea lab as an example to others. > > This includes 48 boards, not all of which work. > > Applied to u-boot/u-boot-test-hooks.git/master, thanks! -- Tom

Re: [u-boot-test-hooks PATCH 2/2] labgrid-sjg: Add systemd scripts

On Fri, Feb 21, 2025 at 01:43:02PM -0700, Simon Glass wrote: > Add example scripts to start the coordinator and exporter. > > Signed-off-by: Simon Glass > --- > > labgrid-sjg/labgrid-coordinator.service | 14 ++ > labgrid-sjg/labgrid-exporter.service| 22 ++

Re: [u-boot-test-hooks PATCH 3/3] RFC: Add some network info for ellesmere lab

On Fri, Feb 21, 2025 at 01:32:42PM -0700, Simon Glass wrote: > Provide network configuration so that some networking tests can be run > on ellesmere. > > Signed-off-by: Simon Glass > --- > > py/ellesmere/ellesmere_tftp.py| 32 Erm, can't you just use py/travis-c

Re: u-boot in restricted environment: networking over serial

Hi Ferenc, On 03.02.25 13:31, Ferenc Fejes wrote: > On Mon, 2025-02-03 at 13:08 +0100, Ahmad Fatoum wrote: >> On 30.01.25 14:55, Ferenc Fejes wrote: >>> >>> Thanks in advance for any hint! >> >> If you are willing to implement it, there's RFC 916 (RATP), which >> addresses the use case of establis

Re: u-boot in restricted environment: networking over serial

Hi Ahmad, On Mon, 2025-02-03 at 13:08 +0100, Ahmad Fatoum wrote: > Hi, > > On 30.01.25 14:55, Ferenc Fejes wrote: > > Hi, > > > > Is it possible to use the serial port for u-boot networking? For example, > > given > > a restricted environment where the FIT image is available with ethernet > > fi

Re: u-boot in restricted environment: networking over serial

Hi, On 30.01.25 14:55, Ferenc Fejes wrote: > Hi, > > Is it possible to use the serial port for u-boot networking? For example, > given > a restricted environment where the FIT image is available with ethernet > firmware > and drivers, so it is not possible to boot it with DHCP boot since there

Re: [U-Boot][PATCH v5 0/5] Improve fpga cmd usage information

On 1/21/25 14:01, Ibai Erkiaga wrote: Current usage information is not read friendly specially when all the options are selected. This series fix some of the issues in the info, aligment and overlapping issues, excess of verbosity on the loads... Additionally Xilinx exclusive com

Re: u-boot in restricted environment: networking over serial

On Thu, 2025-01-30 at 11:04 -0600, Tom Rini wrote: > On Thu, Jan 30, 2025 at 02:55:53PM +0100, Ferenc Fejes wrote: > > > Hi, > > > > Is it possible to use the serial port for u-boot networking? For example, > > given > > a restricted environment where the FIT image is available with ethernet > >

Re: u-boot in restricted environment: networking over serial

On Thu, Jan 30, 2025 at 02:55:53PM +0100, Ferenc Fejes wrote: > Hi, > > Is it possible to use the serial port for u-boot networking? For example, > given > a restricted environment where the FIT image is available with ethernet > firmware > and drivers, so it is not possible to boot it with DHC

RE: [U-Boot][PATCH v4 5/5] fpga: add new symbol for fpga_loadb

[AMD Official Use Only - AMD Internal Distribution Only] Hi Michal > -Original Message- > From: Simek, Michal > Sent: Monday, January 20, 2025 1:04 PM > To: Erkiaga Elorza, Ibai ; u-boot@lists.denx.de > Cc: a...@thorsis.com > Subject: Re: [U-Boot][PATCH v4 5/5] fpga:

Re: [U-Boot][PATCH v4 1/5] fpga: fix alignment on fpga cmd usage info

On 1/20/25 13:43, Ibai Erkiaga wrote: The current implementation generates some alignment issues as well as some overlapping when all the fpga command options are enabled. The fix is intended to improve readability of the usage info. Signed-off-by: Ibai Erkiaga --- You got ack for this one

Re: [U-Boot][PATCH v4 5/5] fpga: add new symbol for fpga_loadb

On 1/20/25 13:43, Ibai Erkiaga wrote: Adding new symbol for the fpga loadb command which is exclusive to Xilinx. Default value is y for backward compatibility. Signed-off-by: Ibai Erkiaga --- (no changes since v1) cmd/Kconfig | 7 +++ cmd/fpga.c | 8 ++-- 2 files changed, 13 i

Re: [U-Boot][PATCH v3 4/4] fpga: xilinx exclusive commands

On 1/17/25 12:25, Ibai Erkiaga wrote: Ensure all Xilinx exclusive fpga commands have a KConfig symbol and dependency to FPGA_XILINX listed. Remove (Xilinx only) text from the help command. Signed-off-by: Ibai Erkiaga --- (no changes since v1) cmd/Kconfig | 16 +++- cmd/fpga.

Re: [U-Boot][PATCH v3 4/4] fpga: xilinx exclusive commands

version once Michal finishes his review. Regards Ibai From: Alexander Dahl Sent: 20 January 2025 08:57 To: Erkiaga Elorza, Ibai Cc: u-boot@lists.denx.de ; Simek, Michal Subject: Re: [U-Boot][PATCH v3 4/4] fpga: xilinx exclusive commands Caution: This message

Re: [U-Boot][PATCH v3 4/4] fpga: xilinx exclusive commands

Hello, Am Fri, Jan 17, 2025 at 11:25:51AM + schrieb Ibai Erkiaga: > @@ -1192,7 +1198,7 @@ config CMD_FPGA_LOADMK > config CMD_FPGA_LOAD_SECURE > bool "fpga loads - loads secure bitstreams" > depends on CMD_FPGA > - select FPGA_LOAD_SECURE > + select FPGA_LOAD_SECURE && FPG

Re: [U-Boot][PATCH v3 1/4] fpga: fix alignment on fpga cmd usage info

Hello, Am Fri, Jan 17, 2025 at 11:25:48AM + schrieb Ibai Erkiaga: > The current implementation generates some alignment issues as well as > some overlapping when all the fpga command options are enabled. The fix > is intended to improve readability of the usage info. > > Signed-off-by: Ibai E

Re: [U-Boot][PATCH v2 3/3] fpga: xilinx exclusive commands info

On 1/17/25 10:28, Ibai Erkiaga wrote: Remove statements of Xilinx Only from the fpga command information and ensure Kconfig dependencies to FPGA_XILINX are implemented instead. you are actually doing more than you write. You are also resorting commands which is kind of messy. Signed-off

Re: [U-Boot][PATCH 1/2] fpga: fix alignment on fpga cmd usage info

On 1/8/25 15:03, Ibai Erkiaga wrote: The current implementation generates some alignment issues as well as some overlapping when all the fpga command options are enabled. The fix is intended to improve readability of the usage info. Signed-off-by: Ibai Erkiaga --- The current output looks

Re: [U-Boot][PATCH 2/2] fpga: improve loads usage information

On 1/8/25 15:03, Ibai Erkiaga wrote: Current usage information for loads command is too verbose and long for a command usage prompt. This flag simplifies the text for readability purposes. Signed-off-by: Ibai Erkiaga --- The authentication and encryption flag naming is redundant with the de

Re: [U-Boot][PATCH 1/2] fpga: fix alignment on fpga cmd usage info

gards Ibai *From:* Alexander Dahl *Sent:* 09 January 2025 07:52 *To:* Erkiaga Elorza, Ibai *Cc:* u-boot@lists.denx.de ; Simek, Michal *Subject:* Re: [U-Boot][PATCH 1/2] fpga: fix alignment on fpga cmd usage info Caution: Th

Re: [U-Boot][PATCH] zynqmp_gqspi: update to log_debug

On 1/7/25 15:51, Ibai Erkiaga wrote: Update recent parallel memory support code to move to log_debug instead of debug as per logging in U-Boot documentation Signed-off-by: Ibai Erkiaga --- drivers/spi/zynqmp_gqspi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/driv

Re: [U-Boot][PATCH 1/2] fpga: fix alignment on fpga cmd usage info

Sent: 09 January 2025 07:52 To: Erkiaga Elorza, Ibai Cc: u-boot@lists.denx.de ; Simek, Michal Subject: Re: [U-Boot][PATCH 1/2] fpga: fix alignment on fpga cmd usage info Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or

Re: [U-Boot][PATCH 1/2] fpga: fix alignment on fpga cmd usage info

Hello, Am Wed, Jan 08, 2025 at 02:03:50PM + schrieb Ibai Erkiaga: > The current implementation generates some alignment issues as well as > some overlapping when all the fpga command options are enabled. The fix > is intended to improve readability of the usage info. Alignment could indeed im

Re: [U-BOOT PATCH] sunxi: add support for Rervision A33-Vstar board

在 2024-12-11星期三的 15:22 +，Andre Przywara写道： > On Wed, 11 Dec 2024 22:07:38 +0800 > Icenowy Zheng wrote: > > Hi, > > > 在 2024-12-11星期三的 13:14 +，Andre Przywara写道： > > > On Wed, 11 Dec 2024 15:21:48 +0800 > > > Icenowy Zheng wrote: > > > > > > Hi Icenowy, > > > > > > thanks for sending th

Re: [U-BOOT PATCH] sunxi: add support for Rervision A33-Vstar board

在 2024-12-11星期三的 15:22 +，Andre Przywara写道： > On Wed, 11 Dec 2024 22:07:38 +0800 > Icenowy Zheng wrote: > > Hi, > > > 在 2024-12-11星期三的 13:14 +，Andre Przywara写道： > > > On Wed, 11 Dec 2024 15:21:48 +0800 > > > Icenowy Zheng wrote: > > > > > > Hi Icenowy, > > > > > > thanks for sending th

Re: [U-BOOT PATCH] sunxi: add support for Rervision A33-Vstar board

On Wed, 11 Dec 2024 22:07:38 +0800 Icenowy Zheng wrote: Hi, > 在 2024-12-11星期三的 13:14 +，Andre Przywara写道： > > On Wed, 11 Dec 2024 15:21:48 +0800 > > Icenowy Zheng wrote: > > > > Hi Icenowy, > > > > thanks for sending the patch! > > > > > 在 2024-12-11星期三的 11:17 +0800，Icenowy Zheng写道： >

Re: [U-BOOT PATCH] sunxi: add support for Rervision A33-Vstar board

在 2024-12-11星期三的 13:14 +，Andre Przywara写道： > On Wed, 11 Dec 2024 15:21:48 +0800 > Icenowy Zheng wrote: > > Hi Icenowy, > > thanks for sending the patch! > > > 在 2024-12-11星期三的 11:17 +0800，Icenowy Zheng写道： > > > Rervision A33-Vstar is an evaluation board for their A33-Core1 > > > A33- > > >

Re: [U-BOOT PATCH] sunxi: add support for Rervision A33-Vstar board

On Wed, 11 Dec 2024 15:21:48 +0800 Icenowy Zheng wrote: Hi Icenowy, thanks for sending the patch! > 在 2024-12-11星期三的 11:17 +0800，Icenowy Zheng写道： > > Rervision A33-Vstar is an evaluation board for their A33-Core1 A33- > > based > > SoM. > > > > Add support for it. > > > > Fastboot support is

Re: [U-BOOT PATCH] sunxi: add support for Rervision A33-Vstar board

在 2024-12-11星期三的 11:17 +0800，Icenowy Zheng写道： > Rervision A33-Vstar is an evaluation board for their A33-Core1 A33- > based > SoM. > > Add support for it. > > Fastboot support is enabled for flashing the eMMC included within the > SoM, and R8152 Ethernet is enabled for the evaluation board's onbo

Re: u-boot mailing list issues

On Mon, Nov 25, 2024 at 03:04:05PM +1300, Chris Packham wrote: > Hi, > > I've noticed a few odd things on the u-boot mailing list lately. > > A couple of weeks ago I seemed to stop getting new messages. At first > I thought this was just gmail deciding to helpfully file messages away > for me bu

Re: [u-boot PATCH] fs: btrfs: hide 'Cannot lookup file' errors on 'load'

On Wed, Nov 13, 2024 at 02:58:42PM +0900, Dominique Martinet wrote: > Dominique Martinet wrote on Wed, Nov 06, 2024 at 09:56:42AM +0900: > > Running commands such as 'load mmc 2:1 $addr $path' when path does not > > exists historically do not print any error on filesystems such as ext4 > > or fat.

Re: [u-boot PATCH] fs: btrfs: hide 'Cannot lookup file' errors on 'load'

Dominique Martinet wrote on Wed, Nov 06, 2024 at 09:56:42AM +0900: > Running commands such as 'load mmc 2:1 $addr $path' when path does not > exists historically do not print any error on filesystems such as ext4 > or fat. > Changing the root filesystem to btrfs would make existing boot script > pr

Re: [u-boot PATCH] fs: btrfs: hide 'Cannot lookup file' errors on 'load'

在 2024/11/6 11:59, Dominique Martinet 写道: Running commands such as 'load mmc 2:1 $addr $path' when path does not exists historically do not print any error on filesystems such as ext4 or fat. Changing the root filesystem to btrfs would make existing boot script print 'Cannot lookup file xxx' e

Re: [u-boot-test-hooks][PATCH] labgrid: Add wrapper scripts around using labgrid-client for device control

On Thu, Aug 29, 2024 at 12:56:20PM -0600, Tom Rini wrote: > From: Edi Feschiyan > > General usage for these hooks is documented in the README.md file. In > terms of implementation, To start with, we add a common file to ensure > that all required environment variables are set. Next, we add a con

Re: [u-boot-test-hooks PATCH v5 0/3] Add support for Labgrid

On Mon, 04 Nov 2024 11:36:40 -0700, Simon Glass wrote: > This adds hooks for use with my integration for Labgrid (called > Labgrid-sjg). The only existing hook that really does anything with the > target, with this integration, is the 'console' one. There is also a new > 'getrole' hook which looks

  1   2   3   4   5   6   7   8   9   10   >