Hello,
On 7/22/25 17:48, Enric Balletbo i Serra wrote:
> * Introduce a new config option OPENSSL_NO_DEPRECATED.
> This option will allow building U-Boot without any ENGINE support.
> When enabled, hardware-backed signing (PKCS#11, etc.) will not be
> available, but U-Boot will be buildable on dist
Hi Udit,
On 4/25/25 12:35, Kumar, Udit wrote:
> On 4/25/2025 11:09 AM, Ahmad Fatoum wrote:
>> Thinking about it, I am wondering whether U-Boot go is inherently broken,
>> even for the jump-table use case, if caches are enabled:
>
> Correct, this is what I think . Before jump
Hi Udit,
On 25.04.25 06:35, Kumar, Udit wrote:
>
> On 4/23/2025 7:52 PM, Ahmad Fatoum wrote:
>> I went with the FIT route for barebox, because we can now ship device
>> trees for all enabled boards in the same FIT image alongside one generic
>> second stage barebox with
Hi,
On 4/23/25 14:28, Simon Glass wrote:
> Hi Anshul,
>
> On Wed, 23 Apr 2025 at 04:04, Anshul Dalal wrote:
>>
>> Hi all,
>>
>> I was trying to understand how the go command is expected to work when
>> used to load custom OSes. My use case requires getting a proprietary OS
>> to boot using the g
Hi,
On 17.04.25 16:16, Tom Rini wrote:
> On Thu, Apr 17, 2025 at 06:30:13AM -0500, Nishanth Menon wrote:
I dont see a specific value here. U-boot just works. For folks who want
direct TFA to kernel jump (which is a niche fast boot usecase), go ahead
and use TFA with the mentioned bu
Hello,
Quentin, thanks for starting this discussion.
On 10.02.25 17:25, Quentin Schulz wrote:
> On 2/9/25 3:28 PM, Simon Glass wrote:
>> On Thu, 6 Feb 2025 at 08:46, Quentin Schulz wrote:
> diff --git a/source/chapter3-devicenodes.rst
> b/source/chapter3-devicenodes.rst
> index
>>>
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 91
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
Hi,
On 31.01.25 17:10, Yao Zi wrote:
> On Tue, Jan 28, 2025 at 11:19:15AM +0100, Jerome Forissier wrote:
>> +.globl _co_switch
>> +.type _co_switch, @function
>> +_co_switch:
>> +// x0: from_co
>> +// x1: to_co
>> +// from_co and to_co layout: { pc, sp, x19-x29 }
>> +
>> +// Save
Hi Pierre,
On 08.01.25 16:52, Pierre-Clément Tosi wrote:
> Hi Caleb,
>
> On Wed, Jan 08, 2025 at 04:19:07PM +0100, Caleb Connolly wrote:
>> Hi Marc,
>>
>> Thanks for your comments.
>>
>> On 08/01/2025 16:05, Marc Zyngier wrote:
>>> On Wed, 08 Jan 2025 14:22:24 +,
>>> Caleb Connolly wrote:
>>
Hi Neil,
On 30.12.24 11:35, Neil Armstrong wrote:
> On 28/12/2024 14:46, Ahmad Fatoum wrote:
>> Doing cache maintenance on DMA-coherent memory doesn't make sense.
>> If this makes things better for you, it's probable that something else
>> is broken.
>>
>&
Hi,
On 11.10.24 16:38, Neil Armstrong wrote:
> On Qualcomm systems, the setup buffer and even buffers are in
> a bad state at interrupt handling, so invalidate the dcache lines
> for the setup_buf and event buffer to make sure we read correct
> data written by the hardware.
>
> This fixes the fol
Hello Ye Li,
On 20.12.24 02:58, Ye Li wrote:
> On 12/19/2024 6:27 PM, Ahmad Fatoum wrote:
>> On 30.09.24 08:38, Peng Fan wrote:
>>>> I now have the DDR settings for an i.MX9 LPDDR4 board in front of me
>>>> that has different contents for struct
>>>>
Hello Peng,
On 30.09.24 08:38, Peng Fan wrote:
>> Subject: i.MX8/9: question about unused DDR PHY trained CSR board
>> array
>> Looking at the DDR setup code for i.MX8M and i.MX9 that you had
>> contributed, I am wondering about struct
>> dram_cfg_param::ddrphy_trained_csr and the global
>> ddrphy
Hi,
This is a heads up that the U-Boot image generated by qemu_arm64_defconfig
crashes during xhci-pci probe when running under KVM on a native ARM host:
Bus xhci_pci: Register 8001040 NbrPorts 8
Starting the controller
"Synchronous Abort" handler, esr 0x9610, far 0x10090040
elr:
Hello Peng,
Looking at the DDR setup code for i.MX8M and i.MX9 that you had contributed,
I am wondering about struct dram_cfg_param::ddrphy_trained_csr and the global
ddrphy_trained_csr array.
struct dram_cfg_param::ddrphy_trained_csr is presumably generated by the
i.MX DDR tool and it seems popu
Hi,
On 03.01.24 13:44, Heinrich Schuchardt wrote:
> On 03.01.24 11:11, Csókás Bence wrote:
>> Hi,
>>
>> 2023. 12. 31. 0:54 keltezéssel, Heinrich Schuchardt írta:
>>> On 12/20/23 05:11, Simon Glass wrote:
+Heinrich Schuchardt
On Tue, 19 Dec 2023 at 13:33, Daniel Golle
wrote:
>>
Hello Yamada-san,
On 14.12.23 08:33, Masahiro Yamada wrote:
>> The FIT spec allows the "fdt" property to list
>> multiple image nodes.
>>
>>
>> o config-1
>> |- description = "configuration description"
>> |- kernel = "kernel sub-node unit name"
>> |- fdt = "fdt sub-node unit-name" [, "fdt over
for
> $(obj)/image.fit
>
> While FIT supports a ramdisk / initrd, no attempt is made to support
> this here, since it must be built separately from the Linux build.
>
> Signed-off-by: Simon Glass
kernel_noload support is now in barebox next branch and I tested this
series ag
Hello,
On 04.12.23 18:52, Doug Anderson wrote:> On Sat, Dec 2, 2023 at 8:37 AM Simon
Glass wrote:
>> On Thu, 30 Nov 2023 at 19:04, Ahmad Fatoum wrote:
>>> On 30.11.23 21:30, Simon Glass wrote:
>>>> On Wed, 29 Nov 2023 at 12:54, Ahmad Fatoum wrote:
>>>
Hello Simon,
On 30.11.23 21:30, Simon Glass wrote:
> On Wed, 29 Nov 2023 at 12:54, Ahmad Fatoum wrote:
>> On 29.11.23 20:44, Simon Glass wrote:
>>> On Wed, 29 Nov 2023 at 12:33, Ahmad Fatoum wrote:
>>>>
>>>> On 29.11.23 20:27, Simon Glass wrote:
>&g
Hi Simon,
On 29.11.23 20:00, Simon Glass wrote:
> On Wed, 29 Nov 2023 at 11:35, Ahmad Fatoum wrote:
>> Doesn't hardcoding a load address and entry address here defeat the point
>> of having FIT as generic portable image format?
>>
>> At least barebox will
Hello Simon,
On 29.11.23 20:44, Simon Glass wrote:
> Hi Ahmad,
>
> On Wed, 29 Nov 2023 at 12:33, Ahmad Fatoum wrote:
>>
>> On 29.11.23 20:27, Simon Glass wrote:
>>> On Wed, 29 Nov 2023 at 12:15, Ahmad Fatoum wrote:
>>>> On 29.11.23 20:02, Simon Glass
On 29.11.23 20:27, Simon Glass wrote:
> On Wed, 29 Nov 2023 at 12:15, Ahmad Fatoum wrote:
>> On 29.11.23 20:02, Simon Glass wrote:
>>> On Wed, 29 Nov 2023 at 11:59, Ahmad Fatoum wrote:
>>>> The specification says that this is the root U-Boot compatible,
>>>
Hello Tom,
On 29.11.23 20:02, Tom Rini wrote:
> On Wed, Nov 29, 2023 at 07:59:00PM +0100, Ahmad Fatoum wrote:
>> Hi,
>>
>> a few more comments after decompiling the FIT image:
>>
>> On 29.11.23 18:21, Simon Glass wrote:
>>> +with fsw.add_node(&
Hello Simon,
On 29.11.23 20:02, Simon Glass wrote:
> Hi Ahmad,
>
> On Wed, 29 Nov 2023 at 11:59, Ahmad Fatoum wrote:
>>
>> Hi,
>>
>> a few more comments after decompiling the FIT image:
>>
>> On 29.11.23 18:21, Simon Gl
Hi,
a few more comments after decompiling the FIT image:
On 29.11.23 18:21, Simon Glass wrote:
> +with fsw.add_node('kernel'):
> +fsw.property_string('description', args.name)
> +fsw.property_string('type', 'kernel_noload')
The specification only says no loading done, but doe
Hello Simon,
On 29.11.23 18:21, Simon Glass wrote:
> Add a script which produces a Flat Image Tree (FIT), a single file
> containing the built kernel and associated devicetree files.
> Compression defaults to gzip which gives a good balance of size and
> performance.
Thanks for working on this. I
> +++ b/drivers/virtio/virtio_console.c
> @@ -0,0 +1,158 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2018, Tuomas Tynkkynen
> + * Copyright (C) 2018, Bin Meng
> + * Copyright (C) 2006, 2007, 2009 Rusty Russell, IBM Corporation
> + * Copyri
On 10.01.23 11:54, Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> This is required by layouts that need to read whole NVMEM space. It
> applies to NVMEM devices without hardcoded layout (like U-Boot
> environment data block).
>
> Signed-off-by: Rafał Miłecki
> ---
> drivers/nvmem/core.c
Hello Rafał,
On 18.08.22 06:38, Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> This fixes:
> drivers/nvmem/u-boot-env.c:141:17: sparse: sparse: cast to restricted __le32
>
> Reported-by: kernel test robot
> Fixes: f955dc1445069 ("nvmem: add driver handling U-Boot environment
> variables")
> S
tting them also by a DT node.
>
> This API is required for drivers handling DT defined MTD partitions in a
> specific way (e.g. U-Boot (sub)partition with environment variables).
>
> Signed-off-by: Rafał Miłecki
> Acked-by: Miquel Raynal
Reviewed-by: Ahmad Fatoum
Hello Rafał,
On 11.06.22 22:46, Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> MTD subsystem API allows interacting with MTD devices (e.g. reading,
> writing, handling bad blocks). So far a random driver could get MTD
> device only by its name (get_mtd_device_nm()). This change allows
> getting
Hello Rafał,
On 11.06.22 22:46, Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> U-Boot stores its setup as environment variables. It's a list of
> key-value pairs stored on flash device with a custom header.
>
> This commit adds an NVMEM driver that:
> 1. Provides NVMEM access to environment var
Hello Rafał,
On 05.05.22 07:46, Rafał Miłecki wrote:
> On 4.05.2022 11:23, Ahmad Fatoum wrote:
>> Hello Rafał,
>>
>> On 03.05.22 18:56, Rafał Miłecki wrote:
>>> From: Rafał Miłecki
>>>
>>> U-Boot stores its setup as environment variables. It's
Hello Rafał,
On 03.05.22 18:56, Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> U-Boot stores its setup as environment variables. It's a list of
> key-value pairs stored on flash device with a custom header.
>
> This commit adds an NVMEM driver that:
> 1. Provides NVMEM access to environment var
Hello Patrick,
On 15.07.21 17:22, Patrick Delaunay wrote:
> With FIP support in TF-A (when CONFIG_STM32MP15x_STM32IMAGE
> is not activated), the DT nodes needed by OP-TEE are added by OP-TEE
> firmware in U-Boot device tree, present in FIP.
What about the SCMI nodes. Who will fix up those?
> The
Hello Patrick,
On 19.02.21 14:30, Patrick DELAUNAY wrote:
> Hi Ahmad,
>
> On 2/11/21 12:14 PM, Ahmad Fatoum wrote:
>> Hi,
>>
>> On 10.02.21 20:59, Tom Rini wrote:
>>> On Tue, Feb 09, 2021 at 08:51:26PM +0100, Patrick DELAUNAY wrote:
>>>> On 2/9/21
On 11.02.21 14:02, Tom Rini wrote:
> On Thu, Feb 11, 2021 at 12:14:51PM +0100, Ahmad Fatoum wrote:
>> I think platforms like the STM32MP1 should be handled specially, because
>> they support having an external device tree passed from the FSBL at runtime.
>> See
>> http
Hi,
On 10.02.21 20:59, Tom Rini wrote:
> On Tue, Feb 09, 2021 at 08:51:26PM +0100, Patrick DELAUNAY wrote:
>>
>> On 2/9/21 11:39 AM, Marek Vasut wrote:
>>> On 2/9/21 11:14 AM, Patrick Delaunay wrote:
>>> Hi,
>>>
>>> [...]
>>>
diff --git a/drivers/usb/gadget/dwc2_udc_otg.c
b/drivers/usb/g
On 10/9/20 7:12 PM, Ahmad Fatoum wrote:
> to do within normal world is mapping it XN, cacheable and not be in manager
> domain.
s/cacheable/uncacheable/ of course.
> Unmapping sounds unnecessary to me. (You don't unmap peripherals you aren't
> using either.
> Why han
Hello Patrick,
On 10/9/20 5:52 PM, Patrick DELAUNAY wrote:
> I checked DACR behavior and CheckDomain / CheckPermission
>
> In my case the cortex A7 try to access to part of DDR / mapped cacheable and
> bufferable, protected by firewall.
>
> So to use DACR I always need to configure the MMU wit
Hello Ard, Patrick,
On 10/7/20 12:26 PM, Ard Biesheuvel wrote:
>> The issue is solved only when the region reserved by OP-TEE is no more
>> mapped in U-Boot (mapped as DEVICE/NON-CACHEABLE wasn't enough) as it is
>> already done in Linux kernel.
>>
>
> Spurious peculative accesses to device regio
Hello,
On 10/7/20 1:23 PM, Ahmad Fatoum wrote:
> My findings[1] back then were that U-Boot did set the eXecute Never bit only
> on
> OMAP, but not for other platforms. So I could imagine this being the root
> cause
> of Patrick's issues as well:
Rereading my own link, m
44 matches
Mail list logo
