This helper is used by the EFI driver and we would like to use that on
ARM. Move the helper function into its own file, separate from PCI ROMs,
which are an x86 thing.
Add a forward declaration for struct udevice so that the header can be
included directly.
Signed-off-by: Simon Glass
---
(no ch
This value is not available with the EFI app. Add a condition to avoid
introducing errors when linking.
Signed-off-by: Simon Glass
---
Changes in v4:
- Got back to depending on HAVE_TEXT_BASE
Changes in v2:
- Depend on CONFIG_EFI_APP instead
- Drop change to u-boot-elf rule
Makefile | 2 ++
1
The previous bootloader has already set up the page tables, so don't try
to do it again.
This fixes a crash in QEMU when booting from EDK2
Signed-off-by: Simon Glass
---
(no changes since v1)
arch/arm/lib/cache.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/lib/cache.c b/ar
The 'vendor' concept comes from arch/x86. Rather than letting this
spread around the tree, rename it to ARCH_EFI.
While EFI is not quite an architecture in the strict sense, it is
similar to sandbox in that it sits somewhat above the CPU architecture.
Signed-off-by: Simon Glass
---
Ideas for a b
Provide a function which sets this pointer, for use in the EFI app.
Signed-off-by: Simon Glass
---
(no changes since v1)
arch/x86/include/asm/global_data.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/x86/include/asm/global_data.h
b/arch/x86/include/asm/global_data.h
index
There is no need to use the global struct provided by PCI. Declare a
local structure instead, so this can be used on ARM without including
support for PCI ROMs.
Signed-off-by: Simon Glass
---
(no changes since v1)
drivers/video/efi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/
Introduce an EFI app for arm64 and update the documentation.
Provide a value for LOAD_ADDR to avoid a link error.
Signed-off-by: Simon Glass
---
(no changes since v2)
Changes in v2:
- Use ARCH_EFI instead of VENDOR_EFI
- Merge the linker-script rules into Kconfig in this patch
- Drop patch 'Se
We don't need to manually add the PE header, since binutils has support
for this now. Remove it to simplify the file.
Set the link-target to efi-app-aarch64 so that binutils knows what to
do. Add rules to pick up the arm64 files.
Make some updates to the link-script for arm64, so this all works:
As opposed to the payload, which is built normally with just an EFI
stub, the app is build homogenously using EFI flags. Update
PLATFORM_CPPFLAGS to enable this.
Signed-off-by: Simon Glass
---
(no changes since v1)
arch/arm/cpu/armv8/config.mk | 4
1 file changed, 4 insertions(+)
diff --
The EFI app uses different startup and relocation code and the existing
code uses symbols not present in the app. Drop it.
Signed-off-by: Simon Glass
Reviewed-by: Tom Rini
---
(no changes since v1)
arch/arm/cpu/armv8/Makefile | 2 ++
arch/arm/lib/Makefile | 4 +++-
2 files changed, 5 in
This feature should not be used with the app, since we don't know where
U-Boot will be loaded. Disable it.
Signed-off-by: Simon Glass
Reviewed-by: Tom Rini
---
(no changes since v1)
arch/arm/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/Kconfig b/arch/ar
The app should be built as a shared library, with position-independent
code and the -shared flags. Update the Makefile to handle this.
Signed-off-by: Simon Glass
---
Changes in v4:
- Drop the confusing comment about position-independent code
Makefile | 5 -
1 file changed, 4 insertions(+),
Build in the EFI-app startup code as well as the code to relocate U-Boot
to the loaded position, since this is under the control of the previous
firmware.
Signed-off-by: Simon Glass
Reviewed-by: Tom Rini
---
(no changes since v1)
arch/arm/lib/Makefile | 2 ++
1 file changed, 2 insertions(+)
Adjust the conditions to support the EFI app when running on ARM.
Signed-off-by: Simon Glass
Reviewed-by: Tom Rini
---
(no changes since v2)
Changes in v2:
- Put the EFI-app case first in setup_mon_len(), for clarity
common/board_f.c | 6 +++---
common/board_r.c | 4 +++-
2 files changed, 6
This option cannot be used with a shared library, since it results in
everything being removed. Disable it.
Signed-off-by: Simon Glass
Reviewed-by: Tom Rini
---
(no changes since v1)
arch/arm/config.mk | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/config.mk b/arch/arm/config.
This code is not used with the EFI app, since it enters through a call
to efi_main(). Remove start.S and crt files from the build.
Signed-off-by: Simon Glass
Reviewed-by: Tom Rini
---
(no changes since v1)
arch/arm/Makefile | 2 ++
arch/arm/lib/Makefile | 6 --
2 files changed, 6 inse
It isn't worth the hassle of omitting this field for the app, since code
is shared between the payload and the app. Adjust the condition to avoid
a build error in the 'efi' command with the app on 64-bit ARM.
Signed-off-by: Simon Glass
---
(no changes since v2)
Changes in v2:
- Document the x86
The switch_to_non_secure_mode() function cannot be used since EFI is in
charge of managing exception-levels.
Build just the exceptions.S file.
Modify the existing SPL rule to cater to the EFI app too.
This is quite confusing, so add an issue to clean this up:
https://source.denx.de/u-boot/custo
The previous bootloader has already set up the cache, so don't try to do
it again.
This fixes a crash in QEMU when booting from EDK2
Signed-off-by: Simon Glass
---
(no changes since v1)
common/board_r.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/common/board_r.c
The EFI app likes to use a simple variable for global data. Implement
this for ARM (for use only with 64-bit ARM at present).
Signed-off-by: Simon Glass
Reviewed-by: Tom Rini
---
(no changes since v2)
Changes in v2:
- Mention '64-bit ARM' here, rather than just 'ARM'
arch/arm/include/asm/glo
The previous bootloader has likely done this already, so avoid trying to
do it again. This fixes a crash in QEMU when booting from EDK2
Signed-off-by: Simon Glass
---
(no changes since v1)
arch/arm/lib/bootm.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/arm/
The app does not have this symbol. Also the memory where the app is
loaded is not under U-Boot's control.
There is no sense in relocating from one alloced region to another.
U-Boot is not able to relocate to the top of memory, nor decide what
other parts of memory are used for.
For these reasons,
It is confusing to have a camel-case indentifier in the these files.
Rename them to fit with U-Boot's snake-case style.
The image_base symbol is already used in the x86 link-scripts.
Signed-off-by: Simon Glass
---
(no changes since v2)
Changes in v2:
- Rework the commit message to clarify the
Use the available functions for setting and getting the global_data
pointer so that EFI-startup can operate on 64-bit ARM as well as x86.
Signed-off-by: Simon Glass
---
(no changes since v2)
Changes in v2:
- Mention '64-bit ARM' here, rather than just 'ARM'
lib/efi/efi_app.c | 13
At present only x86 supports the EFI app and (apart from Qualcomm) the
payload. In preparation for supporting 64-bit ARM more generally, rename
the existing ARCH_EFI option to ARCH_EFI_X86, using that to define a
generic ARCH_EFI which will be enabled for all architectures.
Signed-off-by: Simon Gl
So far only x86 supports the EFI app. ARM is going the same way, so
allow these options to be enabled for 64-bit ARM too.
Signed-off-by: Simon Glass
Reviewed-by: Tom Rini
---
(no changes since v2)
Changes in v2:
- Drop the word 'Sadly'
- Mention '64-bit ARM' here, rather than just 'ARM'
arch
This code is not actually x86-specific, so move it into the lib/efi dir
where other archs can use it.
Drop inclusion of the unnecessary x86-specific header.
Signed-off-by: Simon Glass
Reviewed-by: Tom Rini
---
(no changes since v1)
arch/x86/cpu/efi/Makefile | 1 -
lib/efi/Makefile
Hi Tom,
On Mon, 10 Feb 2025 at 07:51, Tom Rini wrote:
>
> On Mon, Feb 10, 2025 at 06:06:38AM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Sun, 9 Feb 2025 at 11:05, Tom Rini wrote:
> > >
> > > On Sat, Feb 08, 2025 at 10:11:21AM -0700, Simon Glass wrote:
> > > > This value is only available if
Since we plan to support the EFI app and payload on 64-bit ARM too,
rename the x86 target.
Adjust the Kconfig rules to allow non-x86 builds to be added.
Signed-off-by: Simon Glass
Reviewed-by: Tom Rini
---
(no changes since v2)
Changes in v2:
- Mention '64-bit ARM' here, rather than just 'ARM
This function calls dm_pci_read_bar32() which is only available if PCI
is enabled. Add this condition here too, so that the EFI app can build
without needing --gc-sections
Signed-off-by: Simon Glass
Reviewed-by: Matthias Brugger
Reviewed-by: Tom Rini
---
(no changes since v1)
lib/fdtdec.c |
From: Liya Huang <1425075...@qq.com>
Compiling with CONFIG_CC_OPTIMIZE_FOR_DEBUG=y
without CONFIG_EFI_LOADER enabled will result in an
undefined reference to 'efi_add_memory_map_pg'.
The make command is as follows:
export CROSS_COMPILE=arm-none-eabi- ARCH=arm
make stm32h750-art-pi_defconf
Hi Tom,
On Fri, 14 Feb 2025 at 18:14, Tom Rini wrote:
>
> On Fri, Feb 14, 2025 at 04:52:04PM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Fri, 14 Feb 2025 at 16:43, Tom Rini wrote:
> > >
> > > On Fri, Feb 14, 2025 at 03:46:30PM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Fri
On Fri, Feb 14, 2025 at 04:52:04PM -0700, Simon Glass wrote:
> Hi Tom,
>
> On Fri, 14 Feb 2025 at 16:43, Tom Rini wrote:
> >
> > On Fri, Feb 14, 2025 at 03:46:30PM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Fri, 14 Feb 2025 at 14:16, Tom Rini wrote:
> > > >
> > > > On Fri, Feb 14, 20
Hi Tom,
On Fri, 14 Feb 2025 at 16:43, Tom Rini wrote:
>
> On Fri, Feb 14, 2025 at 03:46:30PM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Fri, 14 Feb 2025 at 14:16, Tom Rini wrote:
> > >
> > > On Fri, Feb 14, 2025 at 12:48:33PM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Fri
On Fri, Feb 14, 2025 at 03:46:30PM -0700, Simon Glass wrote:
> Hi Tom,
>
> On Fri, 14 Feb 2025 at 14:16, Tom Rini wrote:
> >
> > On Fri, Feb 14, 2025 at 12:48:33PM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Fri, Feb 14, 2025, 07:39 Tom Rini wrote:
> > > >
> > > > On Thu, Feb 13, 2025
On Mon, 10 Feb 2025 14:29:34 -0600, Judith Mendez wrote:
> Some K3 devices like am62x and am64x have a M4 processor in the MCU
> voltage domain. This patch series introduces remoteproc M4 driver which
> will be used to load firmware into and start the M4 remote core.
>
> This series also adds sup
Hi Tom,
On Fri, 14 Feb 2025 at 14:16, Tom Rini wrote:
>
> On Fri, Feb 14, 2025 at 12:48:33PM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Fri, Feb 14, 2025, 07:39 Tom Rini wrote:
> > >
> > > On Thu, Feb 13, 2025 at 05:09:47PM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Thu,
On Fri, Feb 14, 2025 at 12:48:33PM -0700, Simon Glass wrote:
> Hi Tom,
>
> On Fri, Feb 14, 2025, 07:39 Tom Rini wrote:
> >
> > On Thu, Feb 13, 2025 at 05:09:47PM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Thu, 13 Feb 2025 at 15:59, Tom Rini wrote:
> > > >
> > > > On Thu, Feb 13, 2025
On Fri, Feb 14, 2025 at 3:55 PM Tom Rini wrote:
> Applied to u-boot/next, thanks!
The author's Signed-off-by tag is missing.
Hi Tom,
On Fri, Feb 14, 2025, 07:39 Tom Rini wrote:
>
> On Thu, Feb 13, 2025 at 05:09:47PM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Thu, 13 Feb 2025 at 15:59, Tom Rini wrote:
> > >
> > > On Thu, Feb 13, 2025 at 02:57:59PM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Thu,
On Fri, 31 Jan 2025 11:08:44 +0100, Tomas Peterka wrote:
> Add CONFIG_BOOTCOUNT_ALTBOOTCMD so the developer is able to add
> custom altbootcmd via Kconfig when they enable BOOTCOUNT.
>
Applied to u-boot/next, thanks!
--
Tom
On Fri, Feb 14, 2025 at 03:00:25PM +0100, Jerome Forissier wrote:
> Test uthread scheduling.
>
> Signed-off-by: Jerome Forissier
> ---
> lib/uthread.c | 3 ++-
> test/lib/Makefile | 1 +
> test/lib/uthread.c | 58 ++
> 3 files changed, 61 inser
On Fri, Feb 14, 2025 at 03:00:21PM +0100, Jerome Forissier wrote:
> Add an new internal API called uthread (Kconfig symbol: UTHREAD) which
> provides cooperative multi-tasking. The goal is to be able to improve
> the performance of some parts of U-Boot by overlapping lengthy
> operations. Each uthr
Hi Jon,
Thank you for the patch.
On jeu., févr. 13, 2025 at 13:53, Jonathan Humphreys wrote:
> The current implementation of EFI capsule update uses set_dfu_alt_info() to
> set the dfu_alt_info environment variable with the settings it requires.
> However, set_dfu_alt_info() is doing this for a
Hi Jon, thank you for the patch.
On jeu., févr. 13, 2025 at 13:53, Jonathan Humphreys wrote:
> From: Michal Simek
>
> Directly fill update_info.dfu_string to prepare platforms to switch
> from using dfu_alt_info variable to dfu_string which contains description
> for capsule update when switch
> From: Ilias Apalodimas
> Date: Fri, 14 Feb 2025 15:46:45 +0200
>
> For EFI runtime services, we manage to preserve string literals
> by placing the .efi_runtime section just before .data and preserving
> it when marking the runtime memory by marking surrounding boottime
> code as runtime. This
Hi Heinrich,
On 2/14/25 15:41, Heinrich Schuchardt wrote:
> On 14.02.25 15:00, Jerome Forissier wrote:
>> HAVE_INIJMP will be set by architectures that support initjmp(), a
>> non-standard extension to setjmp()/longjmp() allowing to initialize a
>> jump buffer with a function pointer and a stack p
On 14.02.25 15:00, Jerome Forissier wrote:
Add an new internal API called uthread (Kconfig symbol: UTHREAD) which
provides cooperative multi-tasking. The goal is to be able to improve
the performance of some parts of U-Boot by overlapping lengthy
operations. Each uthread has its own stack allocat
On 14.02.25 15:00, Jerome Forissier wrote:
HAVE_INIJMP will be set by architectures that support initjmp(), a
non-standard extension to setjmp()/longjmp() allowing to initialize a
jump buffer with a function pointer and a stack pointer. This will be
useful to later introduce threads.
How is ini
On Thu, Feb 13, 2025 at 05:09:47PM -0700, Simon Glass wrote:
> Hi Tom,
>
> On Thu, 13 Feb 2025 at 15:59, Tom Rini wrote:
> >
> > On Thu, Feb 13, 2025 at 02:57:59PM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Thu, Feb 13, 2025, 11:03 Tom Rini wrote:
> > > >
> > > > On Thu, Feb 13, 2025
On 14.02.25 15:00, Jerome Forissier wrote:
Implement initjmp() for Arm.
Could you, please, describe in the commit message what initjmp() good
for and why it is needed and why it would not be needed for any other
architectures but ARM.
Signed-off-by: Jerome Forissier
---
arch/Kconfig
Add an new internal API called uthread (Kconfig symbol: UTHREAD) which
provides cooperative multi-tasking. The goal is to be able to improve
the performance of some parts of U-Boot by overlapping lengthy
operations. Each uthread has its own stack allocated on the heap. The
default stack size is def
Test the initjmp() function when HAVE_INITJMP is set.
Signed-off-by: Jerome Forissier
---
test/lib/Makefile | 1 +
test/lib/initjmp.c | 72 ++
2 files changed, 73 insertions(+)
create mode 100644 test/lib/initjmp.c
diff --git a/test/lib/Makefile b/
Test uthread scheduling.
Signed-off-by: Jerome Forissier
---
lib/uthread.c | 3 ++-
test/lib/Makefile | 1 +
test/lib/uthread.c | 58 ++
3 files changed, 61 insertions(+), 1 deletion(-)
create mode 100644 test/lib/uthread.c
diff --git a/lib/u
Use the uthread framework to initialize and scan USB buses in parallel
for better performance. Tested on two platforms:
1. arm64 QEMU on a somewhat contrived example (4 USB buses, each with
one audio device, one keyboard, one mouse and one tablet)
$ make qemu_arm64_defconfig
$ make -j$(nproc) C
To prepare for the introduction of coroutines in the USB initialization
sequence, move code out of usb_init() into a new helper function:
usb_init_bus(). No functional change.
Signed-off-by: Jerome Forissier
---
drivers/usb/host/usb-uclass.c | 88 +++
1 file chang
Introduce a uthread scheduling call into udelay() when CONFIG_UTHREAD
is enabled. This means that any uthread calling into udelay() may yield
to uthread and be scheduled again later.
TBD: check if udelay_yield is really necessary.
Signed-off-by: Jerome Forissier
---
lib/time.c | 17
Add ininijmp() to sandbox. The implementation is taken verbatim from
barebox [1]. It is quite complex because contrary to U-Boot platform
code we don't know how the system's C library implements the jump
buffer, so we can't just write the function and stack pointers into it.
FIXME: this patch shou
Implement initjmp() for RISC-V.
Signed-off-by: Jerome Forissier
---
arch/Kconfig| 1 +
arch/riscv/include/asm/setjmp.h | 1 +
arch/riscv/lib/setjmp.S | 10 ++
3 files changed, 12 insertions(+)
diff --git a/arch/Kconfig b/arch/Kconfig
index 57695fada8d..b745
This is a rework of the "Coroutines" RFC v2 series [1] which allowed to
run functions in parallel, and more specifically the ones that rely
on udelay() to poll hardware and wait for some event to happen. With
that we have shown that some intializations could be sped up
(namely, efi_init_obj_list())
Implement initjmp() for Arm.
Signed-off-by: Jerome Forissier
---
arch/Kconfig | 1 +
arch/arm/include/asm/setjmp.h | 1 +
arch/arm/lib/setjmp.S | 11 +++
arch/arm/lib/setjmp_aarch64.S | 9 +
4 files changed, 22 insertions(+)
diff --git a/arch/Kconfig
HAVE_INIJMP will be set by architectures that support initjmp(), a
non-standard extension to setjmp()/longjmp() allowing to initialize a
jump buffer with a function pointer and a stack pointer. This will be
useful to later introduce threads.
Signed-off-by: Jerome Forissier
---
arch/Kconfig | 6 +
Apologies to both for the noise,
I forgot to mark this as v2 and add a changelog
On Fri, 14 Feb 2025 at 15:46, Ilias Apalodimas
wrote:
>
> For EFI runtime services, we manage to preserve string literals
> by placing the .efi_runtime section just before .data and preserving
> it when marking
Hi Yannic,
On Fri, 14 Feb 2025 at 00:18, Yannic Moog wrote:
>
> Hi Simon,
>
> On Thu, 2025-02-13 at 07:01 -0700, Simon Glass wrote:
> > Hi Yannic,
> >
> > On Thu, 13 Feb 2025 at 00:15, Yannic Moog wrote:
> > >
> > > Hi Simon,
> > >
> > > On Mon, 2025-02-10 at 06:06 -0700, Simon Glass wrote:
> >
Hi Yannic,
On Fri, 14 Feb 2025 at 00:05, Yannic Moog wrote:
>
> On Thu, 2025-02-13 at 07:01 -0700, Simon Glass wrote:
> > Hi Yannic,
> >
> > On Thu, 13 Feb 2025 at 00:21, Yannic Moog wrote:
> > >
> > > On Mon, 2025-02-10 at 06:08 -0700, Simon Glass wrote:
> > > > On Wed, 29 Jan 2025 at 03:30, Ya
For EFI runtime services, we manage to preserve string literals
by placing the .efi_runtime section just before .data and preserving
it when marking the runtime memory by marking surrounding boottime
code as runtime. This is ok for now but will break if we update any
linker scripts and decouple .te
On Sun, 9 Feb 2025 at 16:28, Simon Glass wrote:
>
> Hi Ilias,
>
> On Thu, 6 Feb 2025 at 05:40, Ilias Apalodimas
> wrote:
> >
> > Hi Simon,
> >
> > On Thu, 6 Feb 2025 at 14:33, Simon Glass wrote:
> > >
> > > Hi Ilias,
> > >
> > > On Thu, 30 Jan 2025 at 00:21, Ilias Apalodimas
> > > wrote:
> > >
> On 08.02.25 01:21, Heinrich Schuchardt wrote:
> We support all JH7110 boards with starfive_visionfive2_defconfig.
> The relevant device-tree is selected at runtime based on EEPROM data.
>
> Support setting $fdtfile to the file name of the DeepComputing Framework
> motherboard (FML13V01) device-t
Hi all!
I was trying to implement falcon boot on TI AM62x EVM with the kernel image on
SD card's filesystem but the following check in `_spl_load` at
`include/spl_load.h:95` fails to -EIO as per the latest commit [89d]:
return read < spl_image->size ? -EIO : 0;
The check seems to be
> On 08.02.25 01:21, Heinrich Schuchardt wrote:
> Add the u-boot device-tree include needed to support the DeepComputing
> Framework motherboard (FML13V01).
>
> Signed-off-by: Heinrich Schuchardt
> ---
> arch/riscv/dts/jh7110-deepcomputing-fml13v01-u-boot.dtsi | 7 +++
> 1 file changed, 7 in
> On 08.02.25 01:21, Heinrich Schuchardt wrote:
> The DeepComputing Framework motherboard is a JH7110 device support by
> the upstream kernel. Add its device-tree to the list of device-trees to be
> included into the starfive_visionfive_defconfig.
>
> Signed-off-by: Heinrich Schuchardt
> ---
> c
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
Hello,
Am Thu, Feb 13, 2025 at 06:41:04PM +0530 schrieb Sughosh Ganu:
> The lmb_map_update_notify() function is used to update the EFI memory
> map based on corresponding changes in the LMB map. This is causing
> build failure with a certain old architecture(armv5) toolchain, when
> building with
73 matches
Mail list logo
