diff mbox series

[1/1] Added arm64 assembly for examples/api crt0

Message ID DM4PR11MB5296B1B9F0CFC701A8B11284E3EE2@DM4PR11MB5296.namprd11.prod.outlook.com
State New
Delegated to: Tom Rini
Headers show
Series [1/1] Added arm64 assembly for examples/api crt0 | expand

Commit Message

Brunham, Kalen May 17, 2024, 7:13 p.m. UTC 
I've encountered a problem when compiling the 'examples/api' directory for ARM64 in U-boot. The problem lies in the assembly code in 'examples/api/crt0.S' where the current CONFIG_ARM code is only 32-bit. When targeting ARM64, a 64-bit version is necessary.

I have proposed a fix by including a 'CONFIG_ARM64' section in the assembly code as shown below.  These changes have been check via https://github.com/u-boot/u-boot/pull/538.

Feedback is welcome.

---
examples/api/crt0.S | 15 +++++++++++++++
1 file changed, 15 insertions(+)

--

Signed-off-by: Kalen Brunham <kalen.brunham@intel.com>

Comments

Brunham, Kalen May 21, 2024, 1:21 p.m. UTC | #1 
Adding Tom Rini. 

Any update from others?

-----Original Message-----
From: Brunham, Kalen <kalen.brunham@intel.com> 
Sent: Friday, May 17, 2024 3:14 PM
To: U-Boot@lists.denx.de
Subject: [PATCH 1/1] Added arm64 assembly for examples/api crt0

I've encountered a problem when compiling the 'examples/api' directory for ARM64 in U-boot. The problem lies in the assembly code in 'examples/api/crt0.S' where the current CONFIG_ARM code is only 32-bit. When targeting ARM64, a 64-bit version is necessary.

I have proposed a fix by including a 'CONFIG_ARM64' section in the assembly code as shown below.  These changes have been check via https://github.com/u-boot/u-boot/pull/538.

Feedback is welcome.

---
examples/api/crt0.S | 15 +++++++++++++++
1 file changed, 15 insertions(+)

diff --git a/examples/api/crt0.S b/examples/api/crt0.S index 57bba9d851..4c23a54b21 100644
--- a/examples/api/crt0.S
+++ b/examples/api/crt0.S
@@ -24,6 +24,21 @@ syscall:
                mtctr     %r11
                bctr

+#elif defined(CONFIG_ARM64)
+
+              .text
+              .globl _start
+_start:
+              ldr           ip0, =search_hint
+              str           sp_el2, [ip0]
+              b             main
+
+
+              .globl syscall
+syscall:
+              ldr           ip0, =syscall_ptr
+              ldr           pc_el2, [ip0]
+
#elif defined(CONFIG_ARM)

               .text
--

Signed-off-by: Kalen Brunham <kalen.brunham@intel.com>
Tom Rini May 21, 2024, 4:25 p.m. UTC | #2 
On Tue, May 21, 2024 at 01:21:01PM +0000, Brunham, Kalen wrote:

> Adding Tom Rini. 
> 
> Any update from others?
> 
> -----Original Message-----
> From: Brunham, Kalen <kalen.brunham@intel.com> 
> Sent: Friday, May 17, 2024 3:14 PM
> To: U-Boot@lists.denx.de
> Subject: [PATCH 1/1] Added arm64 assembly for examples/api crt0
> 
> I've encountered a problem when compiling the 'examples/api' directory for ARM64 in U-boot. The problem lies in the assembly code in 'examples/api/crt0.S' where the current CONFIG_ARM code is only 32-bit. When targeting ARM64, a 64-bit version is necessary.
> 
> I have proposed a fix by including a 'CONFIG_ARM64' section in the assembly code as shown below.  These changes have been check via https://github.com/u-boot/u-boot/pull/538.
> 
> Feedback is welcome.

I would start by asking why you're using the API on ARM64, I don't know
that it even works there otherwise.
Brunham, Kalen May 21, 2024, 4:44 p.m. UTC | #3 
I don't specifically need API, but today this is needed to enable creation of standalone applications which does work on our ARM64.

If the concern is fixing this startup code, then I can come back with a change to the KConfig and Makefiles to enable compiling the hello_world standalone example for ARM64. 

Thanks.

-----Original Message-----
From: Tom Rini <trini@konsulko.com> 
Sent: Tuesday, May 21, 2024 12:26 PM
To: Brunham, Kalen <kalen.brunham@intel.com>
Cc: U-Boot@lists.denx.de
Subject: Re: [PATCH 1/1] Added arm64 assembly for examples/api crt0

On Tue, May 21, 2024 at 01:21:01PM +0000, Brunham, Kalen wrote:

> Adding Tom Rini. 
> 
> Any update from others?
> 
> -----Original Message-----
> From: Brunham, Kalen <kalen.brunham@intel.com>
> Sent: Friday, May 17, 2024 3:14 PM
> To: U-Boot@lists.denx.de
> Subject: [PATCH 1/1] Added arm64 assembly for examples/api crt0
> 
> I've encountered a problem when compiling the 'examples/api' directory for ARM64 in U-boot. The problem lies in the assembly code in 'examples/api/crt0.S' where the current CONFIG_ARM code is only 32-bit. When targeting ARM64, a 64-bit version is necessary.
> 
> I have proposed a fix by including a 'CONFIG_ARM64' section in the assembly code as shown below.  These changes have been check via https://github.com/u-boot/u-boot/pull/538.
> 
> Feedback is welcome.

I would start by asking why you're using the API on ARM64, I don't know that it even works there otherwise.

--
Tom
Tom Rini May 21, 2024, 4:46 p.m. UTC | #4 
On Tue, May 21, 2024 at 04:44:54PM +0000, Brunham, Kalen wrote:

> I don't specifically need API, but today this is needed to enable
> creation of standalone applications which does work on our ARM64.
> 
> If the concern is fixing this startup code, then I can come back with
> a change to the KConfig and Makefiles to enable compiling the
> hello_world standalone example for ARM64. 

But still, why are you doing that? Removing the standalone API itself is
on my TODO list, so understanding why someone would be using that today
rather than just making an EFI application would be helpful.
Brunham, Kalen May 21, 2024, 4:54 p.m. UTC | #5 
Hi Tom,

Fundamentally I want to create standalone applications that can be used to help debug low-level HW issues. The advantage to doing this in U-Boot is to leverage existing drivers and other facilities. I agree this is niche, but is something I saw one of our power-users do recently and are looking to share with our customers. Unfortunately, the Makefiles today make this more difficult than it should be, hence the desire to change this. My current goal is to enable a user to use the stock (unpatched) u-boot to minimally create a hello-world that they can execute following the existing examples/standalone steps.  

Are your plans to deprecate both API and Standalone?

-----Original Message-----
From: Tom Rini <trini@konsulko.com> 
Sent: Tuesday, May 21, 2024 12:47 PM
To: Brunham, Kalen <kalen.brunham@intel.com>
Cc: U-Boot@lists.denx.de
Subject: Re: [PATCH 1/1] Added arm64 assembly for examples/api crt0

On Tue, May 21, 2024 at 04:44:54PM +0000, Brunham, Kalen wrote:

> I don't specifically need API, but today this is needed to enable 
> creation of standalone applications which does work on our ARM64.
> 
> If the concern is fixing this startup code, then I can come back with 
> a change to the KConfig and Makefiles to enable compiling the 
> hello_world standalone example for ARM64.

But still, why are you doing that? Removing the standalone API itself is on my TODO list, so understanding why someone would be using that today rather than just making an EFI application would be helpful.

--
Tom
Tom Rini May 21, 2024, 6:15 p.m. UTC | #6 
On Tue, May 21, 2024 at 04:54:58PM +0000, Brunham, Kalen wrote:

> Hi Tom,
> 
> Fundamentally I want to create standalone applications that can be
> used to help debug low-level HW issues. The advantage to doing this in
> U-Boot is to leverage existing drivers and other facilities. I agree
> this is niche, but is something I saw one of our power-users do
> recently and are looking to share with our customers. Unfortunately,
> the Makefiles today make this more difficult than it should be, hence
> the desire to change this. My current goal is to enable a user to use
> the stock (unpatched) u-boot to minimally create a hello-world that
> they can execute following the existing examples/standalone steps.  
> 
> Are your plans to deprecate both API and Standalone?

So, the next set of questions become:
- Why isn't it just part of U-Boot? Make your tool a new command
  instead.
- If for license reasons you can't, why not just start from some other
  appropriate for your needs licensed skeleton and bootelf your tool?

We have long not done a great job with the U-Boot standalone API stuff,
and for a number of years at this point a lot of the use cases it was
used for could instead be filled by making an EFI application. There's a
well defined API there, there's lots of examples, and frankly for the
license related questions, makes a much nicer answer.

That there's some power users out there making use of standalone to do
useful things is news to me. Some of them speaking up and offering to
be visible in maintaining it would be good (there's Coverity issues and
lack of CI testing, which should be addressed).
Brunham, Kalen May 21, 2024, 11:28 p.m. UTC | #7 
Hi Tom,

Thanks for the feedback. I've been able to build the EFI "hello world" application, but did notice the logic for CONFIG BLK prevents it from being directly enabled even when the dependencies are met, which is why it didn't immediately work for me. Do you know the maintainer of drivers/block/Kconfig that I could review a patch with?

Thanks

-----Original Message-----
From: Tom Rini <trini@konsulko.com>
Sent: Tuesday, May 21, 2024 2:16 PM
To: Brunham, Kalen <kalen.brunham@intel.com>
Cc: U-Boot@lists.denx.de
Subject: Re: [PATCH 1/1] Added arm64 assembly for examples/api crt0

On Tue, May 21, 2024 at 04:54:58PM +0000, Brunham, Kalen wrote:

> Hi Tom,
> 
> Fundamentally I want to create standalone applications that can be 
> used to help debug low-level HW issues. The advantage to doing this in 
> U-Boot is to leverage existing drivers and other facilities. I agree 
> this is niche, but is something I saw one of our power-users do 
> recently and are looking to share with our customers. Unfortunately, 
> the Makefiles today make this more difficult than it should be, hence 
> the desire to change this. My current goal is to enable a user to use 
> the stock (unpatched) u-boot to minimally create a hello-world that 
> they can execute following the existing examples/standalone steps.
> 
> Are your plans to deprecate both API and Standalone?

So, the next set of questions become:
- Why isn't it just part of U-Boot? Make your tool a new command
  instead.
- If for license reasons you can't, why not just start from some other
  appropriate for your needs licensed skeleton and bootelf your tool?

We have long not done a great job with the U-Boot standalone API stuff, and for a number of years at this point a lot of the use cases it was used for could instead be filled by making an EFI application. There's a well defined API there, there's lots of examples, and frankly for the license related questions, makes a much nicer answer.

That there's some power users out there making use of standalone to do useful things is news to me. Some of them speaking up and offering to be visible in maintaining it would be good (there's Coverity issues and lack of CI testing, which should be addressed).

--
Tom
Tom Rini May 21, 2024, 11:46 p.m. UTC | #8 
On Tue, May 21, 2024 at 11:28:10PM +0000, Brunham, Kalen wrote:

> Hi Tom,
> 
> Thanks for the feedback. I've been able to build the EFI "hello world"
> application, but did notice the logic for CONFIG BLK prevents it from
> being directly enabled even when the dependencies are met, which is
> why it didn't immediately work for me. Do you know the maintainer of
> drivers/block/Kconfig that I could review a patch with?

Can you please elaborate on what problem you see? Thanks.
Brunham, Kalen May 22, 2024, 1:25 p.m. UTC | #9 
Hi Tom,

I'm using a defconfig that does not enable any of the configs listed on the default likes for config BLK (MMC, USB, SCSI, etc.), but I do have DM enabled. I cannot however enable BLK as CONFIG_BLK=y is ignored. My current hypothesis is that BLK is being forced to N by the select BLK in other Kconfig files, but I'm not sure. 

Here's the Kconfig for drivers/block:

config BLK
	bool # "Support block devices"
	depends on DM
	default y if MMC || USB || SCSI || NVME || IDE || AHCI || SATA
	default y if EFI_MEDIA || VIRTIO_BLK || PVBLOCK

My current flow is:
make mrproper
make socfpga_agilex5_defconfig
./scripts/kconfig/merge_config.sh -O ./ ./.config ../../my_uboot_config.txt

Here my_uboot_config.txt hsd:

CONFIG_MMC=n
CONFIG_USB=n
CONFIG_DM_MMC=n
CONFIG_SPL_DM_MMC=n
CONFIG_BLK=y
CONFIG_EFI_LOADER=y
CONFIG_CMD_BOOTEFI=y
CONFIG_EFI_LOADER=y
CONFIG_CMD_BOOTEFI_HELLO_COMPILE=y
CONFIG_CMD_BOOTEFI_HELLO=y

The only way I was able to get BLK set to Y was to add another default like || DM_SPI_FLASH, since I do enable SPI flash in this config. 

Thanks.

-----Original Message-----
From: Tom Rini <trini@konsulko.com> 
Sent: Tuesday, May 21, 2024 7:46 PM
To: Brunham, Kalen <kalen.brunham@intel.com>
Cc: U-Boot@lists.denx.de; Heinrich Schuchardt <xypron.glpk@gmx.de>
Subject: Re: [PATCH 1/1] Added arm64 assembly for examples/api crt0

On Tue, May 21, 2024 at 11:28:10PM +0000, Brunham, Kalen wrote:

> Hi Tom,
> 
> Thanks for the feedback. I've been able to build the EFI "hello world"
> application, but did notice the logic for CONFIG BLK prevents it from 
> being directly enabled even when the dependencies are met, which is 
> why it didn't immediately work for me. Do you know the maintainer of 
> drivers/block/Kconfig that I could review a patch with?

Can you please elaborate on what problem you see? Thanks.

--
Tom
Tom Rini May 22, 2024, 2:39 p.m. UTC | #10 
On Wed, May 22, 2024 at 01:25:51PM +0000, Brunham, Kalen wrote:

> Hi Tom,
> 
> I'm using a defconfig that does not enable any of the configs listed on the default likes for config BLK (MMC, USB, SCSI, etc.), but I do have DM enabled. I cannot however enable BLK as CONFIG_BLK=y is ignored. My current hypothesis is that BLK is being forced to N by the select BLK in other Kconfig files, but I'm not sure. 
> 
> Here's the Kconfig for drivers/block:
> 
> config BLK
> 	bool # "Support block devices"
> 	depends on DM
> 	default y if MMC || USB || SCSI || NVME || IDE || AHCI || SATA
> 	default y if EFI_MEDIA || VIRTIO_BLK || PVBLOCK
> 
> My current flow is:
> make mrproper
> make socfpga_agilex5_defconfig
> ./scripts/kconfig/merge_config.sh -O ./ ./.config ../../my_uboot_config.txt
> 
> Here my_uboot_config.txt hsd:
> 
> CONFIG_MMC=n
> CONFIG_USB=n
> CONFIG_DM_MMC=n
> CONFIG_SPL_DM_MMC=n
> CONFIG_BLK=y
> CONFIG_EFI_LOADER=y
> CONFIG_CMD_BOOTEFI=y
> CONFIG_EFI_LOADER=y
> CONFIG_CMD_BOOTEFI_HELLO_COMPILE=y
> CONFIG_CMD_BOOTEFI_HELLO=y
> 
> The only way I was able to get BLK set to Y was to add another default like || DM_SPI_FLASH, since I do enable SPI flash in this config. 

And why are you trying to enable BLK without any block devices?
Brunham, Kalen May 22, 2024, 5:22 p.m. UTC | #11 
Hi Tom,

BLK is currently a dependency for EFI_LOADER as shown in the snippet from lib/efi_loader/Kconfig below. Perhaps the question is why EFI_LOADER requires a block device? If I remove this depends on BLK line, then I can enable EFI and successfully simulate the EFI hello world on my test design. 


config EFI_LOADER
	bool "Support running UEFI applications"
	depends on OF_LIBFDT && ( \
		ARM && (SYS_CPU = arm1136 || \
			SYS_CPU = arm1176 || \
			SYS_CPU = armv7   || \
			SYS_CPU = armv8)  || \
		X86 || RISCV || SANDBOX)
	# We need EFI_STUB_64BIT to be set on x86_64 with EFI_STUB
	depends on !EFI_STUB || !X86_64 || EFI_STUB_64BIT
	# We need EFI_STUB_32BIT to be set on x86_32 with EFI_STUB
	depends on !EFI_STUB || !X86 || X86_64 || EFI_STUB_32BIT
	depends on BLK
	depends on !EFI_APP
	default y if !ARM || SYS_CPU = armv7 || SYS_CPU = armv8

Thanks. 

-----Original Message-----
From: Tom Rini <trini@konsulko.com> 
Sent: Wednesday, May 22, 2024 10:39 AM
To: Brunham, Kalen <kalen.brunham@intel.com>
Cc: U-Boot@lists.denx.de; Heinrich Schuchardt <xypron.glpk@gmx.de>
Subject: Re: [PATCH 1/1] Added arm64 assembly for examples/api crt0

On Wed, May 22, 2024 at 01:25:51PM +0000, Brunham, Kalen wrote:

> Hi Tom,
> 
> I'm using a defconfig that does not enable any of the configs listed on the default likes for config BLK (MMC, USB, SCSI, etc.), but I do have DM enabled. I cannot however enable BLK as CONFIG_BLK=y is ignored. My current hypothesis is that BLK is being forced to N by the select BLK in other Kconfig files, but I'm not sure. 
> 
> Here's the Kconfig for drivers/block:
> 
> config BLK
> 	bool # "Support block devices"
> 	depends on DM
> 	default y if MMC || USB || SCSI || NVME || IDE || AHCI || SATA
> 	default y if EFI_MEDIA || VIRTIO_BLK || PVBLOCK
> 
> My current flow is:
> make mrproper
> make socfpga_agilex5_defconfig
> ./scripts/kconfig/merge_config.sh -O ./ ./.config ../../my_uboot_config.txt
> 
> Here my_uboot_config.txt hsd:
> 
> CONFIG_MMC=n
> CONFIG_USB=n
> CONFIG_DM_MMC=n
> CONFIG_SPL_DM_MMC=n
> CONFIG_BLK=y
> CONFIG_EFI_LOADER=y
> CONFIG_CMD_BOOTEFI=y
> CONFIG_EFI_LOADER=y
> CONFIG_CMD_BOOTEFI_HELLO_COMPILE=y
> CONFIG_CMD_BOOTEFI_HELLO=y
> 
> The only way I was able to get BLK set to Y was to add another default like || DM_SPI_FLASH, since I do enable SPI flash in this config. 

And why are you trying to enable BLK without any block devices?
Tom Rini May 23, 2024, 3:32 p.m. UTC | #12 
On Wed, May 22, 2024 at 05:22:24PM +0000, Brunham, Kalen wrote:

> Hi Tom,
> 
> BLK is currently a dependency for EFI_LOADER as shown in the snippet from lib/efi_loader/Kconfig below. Perhaps the question is why EFI_LOADER requires a block device? If I remove this depends on BLK line, then I can enable EFI and successfully simulate the EFI hello world on my test design. 
> 
> 
> config EFI_LOADER
> 	bool "Support running UEFI applications"
> 	depends on OF_LIBFDT && ( \
> 		ARM && (SYS_CPU = arm1136 || \
> 			SYS_CPU = arm1176 || \
> 			SYS_CPU = armv7   || \
> 			SYS_CPU = armv8)  || \
> 		X86 || RISCV || SANDBOX)
> 	# We need EFI_STUB_64BIT to be set on x86_64 with EFI_STUB
> 	depends on !EFI_STUB || !X86_64 || EFI_STUB_64BIT
> 	# We need EFI_STUB_32BIT to be set on x86_32 with EFI_STUB
> 	depends on !EFI_STUB || !X86 || X86_64 || EFI_STUB_32BIT
> 	depends on BLK
> 	depends on !EFI_APP
> 	default y if !ARM || SYS_CPU = armv7 || SYS_CPU = armv8

Do you recall why this is Heinrich?
Brunham, Kalen May 23, 2024, 4:01 p.m. UTC | #13 
I can see that efi_device_path.c and efi_disk.c both #include blk.h. 

-----Original Message-----
From: Tom Rini <trini@konsulko.com> 
Sent: Thursday, May 23, 2024 11:33 AM
To: Brunham, Kalen <kalen.brunham@intel.com>; Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: U-Boot@lists.denx.de
Subject: Re: [PATCH 1/1] Added arm64 assembly for examples/api crt0

On Wed, May 22, 2024 at 05:22:24PM +0000, Brunham, Kalen wrote:

> Hi Tom,
> 
> BLK is currently a dependency for EFI_LOADER as shown in the snippet from lib/efi_loader/Kconfig below. Perhaps the question is why EFI_LOADER requires a block device? If I remove this depends on BLK line, then I can enable EFI and successfully simulate the EFI hello world on my test design. 
> 
> 
> config EFI_LOADER
> 	bool "Support running UEFI applications"
> 	depends on OF_LIBFDT && ( \
> 		ARM && (SYS_CPU = arm1136 || \
> 			SYS_CPU = arm1176 || \
> 			SYS_CPU = armv7   || \
> 			SYS_CPU = armv8)  || \
> 		X86 || RISCV || SANDBOX)
> 	# We need EFI_STUB_64BIT to be set on x86_64 with EFI_STUB
> 	depends on !EFI_STUB || !X86_64 || EFI_STUB_64BIT
> 	# We need EFI_STUB_32BIT to be set on x86_32 with EFI_STUB
> 	depends on !EFI_STUB || !X86 || X86_64 || EFI_STUB_32BIT
> 	depends on BLK
> 	depends on !EFI_APP
> 	default y if !ARM || SYS_CPU = armv7 || SYS_CPU = armv8

Do you recall why this is Heinrich?
Tom Rini May 24, 2024, 1:48 a.m. UTC | #14 
On Thu, May 23, 2024 at 04:01:31PM +0000, Brunham, Kalen wrote:

> I can see that efi_device_path.c and efi_disk.c both #include blk.h. 

OK, yes. But what I'm asking of Heinrich is, can we easily and cleanly
make that support conditional? Or is there some underlying requirement
at play here?

> 
> -----Original Message-----
> From: Tom Rini <trini@konsulko.com> 
> Sent: Thursday, May 23, 2024 11:33 AM
> To: Brunham, Kalen <kalen.brunham@intel.com>; Heinrich Schuchardt <xypron.glpk@gmx.de>
> Cc: U-Boot@lists.denx.de
> Subject: Re: [PATCH 1/1] Added arm64 assembly for examples/api crt0
> 
> On Wed, May 22, 2024 at 05:22:24PM +0000, Brunham, Kalen wrote:
> 
> > Hi Tom,
> > 
> > BLK is currently a dependency for EFI_LOADER as shown in the snippet from lib/efi_loader/Kconfig below. Perhaps the question is why EFI_LOADER requires a block device? If I remove this depends on BLK line, then I can enable EFI and successfully simulate the EFI hello world on my test design. 
> > 
> > 
> > config EFI_LOADER
> > 	bool "Support running UEFI applications"
> > 	depends on OF_LIBFDT && ( \
> > 		ARM && (SYS_CPU = arm1136 || \
> > 			SYS_CPU = arm1176 || \
> > 			SYS_CPU = armv7   || \
> > 			SYS_CPU = armv8)  || \
> > 		X86 || RISCV || SANDBOX)
> > 	# We need EFI_STUB_64BIT to be set on x86_64 with EFI_STUB
> > 	depends on !EFI_STUB || !X86_64 || EFI_STUB_64BIT
> > 	# We need EFI_STUB_32BIT to be set on x86_32 with EFI_STUB
> > 	depends on !EFI_STUB || !X86 || X86_64 || EFI_STUB_32BIT
> > 	depends on BLK
> > 	depends on !EFI_APP
> > 	default y if !ARM || SYS_CPU = armv7 || SYS_CPU = armv8
> 
> Do you recall why this is Heinrich?
> 
> -- 
> Tom
Jiaxun Yang May 25, 2024, 4:20 p.m. UTC | #15 
在2024年5月21日五月 下午7:15，Tom Rini写道：
[...]
>
> We have long not done a great job with the U-Boot standalone API stuff,
> and for a number of years at this point a lot of the use cases it was
> used for could instead be filled by making an EFI application. There's a
> well defined API there, there's lots of examples, and frankly for the
> license related questions, makes a much nicer answer.

Hi Tom + U-Boot EFI folks,

Sorry for chime in here.

AFAIK there are quite a lot of users of U-Boot API in MIPS world, mostly for
Bare mental applications to perform chip diagnostic or programming stuff.

But I'd agree that there is no benefit to maintain ABI stuff in upstream
for long run.

However, I think people still need an API-like interface for those simple
applications, while many architectures are not supported by U-Boot EFI for
now.

Sadly, most architectures are not covered by UEFI spec, some of them are
violating fundamental assumptions of UEFI spec, like no 1:1 PA VA mapping
or simply being Big Endian.

Do you think it's a good idea to port EFI support to as many architectures
as possible, and produce U-Boot supplements to UEFI spec to cover those
details? I'm happy to look into it.

Thanks

>
> That there's some power users out there making use of standalone to do
> useful things is news to me. Some of them speaking up and offering to
> be visible in maintaining it would be good (there's Coverity issues and
> lack of CI testing, which should be addressed).
>
> -- 
> Tom
>
> 附件:
> * signature.asc
Ilias Apalodimas May 25, 2024, 7:14 p.m. UTC | #16 
Hi Jiaxun

On Sat, 25 May 2024 at 19:21, Jiaxun Yang <jiaxun.yang@flygoat.com> wrote:
>
>
>
> 在2024年5月21日五月 下午7:15，Tom Rini写道：
> [...]
> >
> > We have long not done a great job with the U-Boot standalone API stuff,
> > and for a number of years at this point a lot of the use cases it was
> > used for could instead be filled by making an EFI application. There's a
> > well defined API there, there's lots of examples, and frankly for the
> > license related questions, makes a much nicer answer.
>
> Hi Tom + U-Boot EFI folks,
>
> Sorry for chime in here.
>
> AFAIK there are quite a lot of users of U-Boot API in MIPS world, mostly for
> Bare mental applications to perform chip diagnostic or programming stuff.
>
> But I'd agree that there is no benefit to maintain ABI stuff in upstream
> for long run.
>
> However, I think people still need an API-like interface for those simple
> applications, while many architectures are not supported by U-Boot EFI for
> now.
>
> Sadly, most architectures are not covered by UEFI spec, some of them are
> violating fundamental assumptions of UEFI spec, like no 1:1 PA VA mapping
> or simply being Big Endian.
>
> Do you think it's a good idea to port EFI support to as many architectures
> as possible, and produce U-Boot supplements to UEFI spec to cover those
> details? I'm happy to look into it.

I personally think U-Boot is a nice alternative to EDK2 for smaller
devices (and doesn't have to rely on the PI spec as well).
The EFI spec does have some architecture specific wording for the
supported platforms, so I would guess adding more would be possible.
But I haven't checked the extent of changes that are going to be
needed.

In any case, I am happy to help

Cheers
/Ilias
>
> Thanks
>
> >
> > That there's some power users out there making use of standalone to do
> > useful things is news to me. Some of them speaking up and offering to
> > be visible in maintaining it would be good (there's Coverity issues and
> > lack of CI testing, which should be addressed).
> >
> > --
> > Tom
> >
> > 附件:
> > * signature.asc
>
> --
> - Jiaxun
Tom Rini May 27, 2024, 4:07 p.m. UTC | #17 
On Sat, May 25, 2024 at 05:20:43PM +0100, Jiaxun Yang wrote:
> 
> 
> 在2024年5月21日五月 下午7:15，Tom Rini写道：
> [...]
> >
> > We have long not done a great job with the U-Boot standalone API stuff,
> > and for a number of years at this point a lot of the use cases it was
> > used for could instead be filled by making an EFI application. There's a
> > well defined API there, there's lots of examples, and frankly for the
> > license related questions, makes a much nicer answer.
> 
> Hi Tom + U-Boot EFI folks,
> 
> Sorry for chime in here.
> 
> AFAIK there are quite a lot of users of U-Boot API in MIPS world, mostly for
> Bare mental applications to perform chip diagnostic or programming stuff.

To be clear, I'm not saying we need to get rid of the ability to run
random bare metal apps. Just the bit where U-Boot exposes some API for a
few functions. We do not test it, and I do not know how well it works.
For what we provide there I would think just doing whatever one normally
does for basic stdio functionality on bare metal would be fine instead.

But I do need to be louder about my intentions here before just doing
it, so that others which do need / use it can chime in.
Brunham, Kalen May 30, 2024, 2:53 p.m. UTC | #18 
Hi Tom,

What are next steps on this change?

I'm committed to the idea of EFI apps opposed to examples/standalone.
EFI currently requires block devices which is not enabled when only using flash.

Should config BLK be updated to include DM_SPI_FLASH?
Should we explore how to remove BLK as a dependency for EFI_LOADER?

Thanks.

-----Original Message-----
From: Tom Rini <trini@konsulko.com>
Sent: Monday, May 27, 2024 12:07 PM
To: Jiaxun Yang <jiaxun.yang@flygoat.com>
Cc: Brunham, Kalen <kalen.brunham@intel.com>; Heinrich Schuchardt <xypron.glpk@gmx.de>; Ilias Apalodimas <ilias.apalodimas@linaro.org>; U-Boot@lists.denx.de
Subject: Re: [PATCH 1/1] Added arm64 assembly for examples/api crt0

On Sat, May 25, 2024 at 05:20:43PM +0100, Jiaxun Yang wrote:
> 
> 
> 在2024年5月21日五月 下午7:15，Tom Rini写道：
> [...]
> >
> > We have long not done a great job with the U-Boot standalone API 
> > stuff, and for a number of years at this point a lot of the use 
> > cases it was used for could instead be filled by making an EFI 
> > application. There's a well defined API there, there's lots of 
> > examples, and frankly for the license related questions, makes a much nicer answer.
> 
> Hi Tom + U-Boot EFI folks,
> 
> Sorry for chime in here.
> 
> AFAIK there are quite a lot of users of U-Boot API in MIPS world, 
> mostly for Bare mental applications to perform chip diagnostic or programming stuff.

To be clear, I'm not saying we need to get rid of the ability to run random bare metal apps. Just the bit where U-Boot exposes some API for a few functions. We do not test it, and I do not know how well it works.
For what we provide there I would think just doing whatever one normally does for basic stdio functionality on bare metal would be fine instead.

But I do need to be louder about my intentions here before just doing it, so that others which do need / use it can chime in.

--
Tom
Tom Rini May 31, 2024, 4:02 p.m. UTC | #19 
On Thu, May 30, 2024 at 02:53:17PM +0000, Brunham, Kalen wrote:

> Hi Tom,
> 
> What are next steps on this change?
> 
> I'm committed to the idea of EFI apps opposed to examples/standalone.
> EFI currently requires block devices which is not enabled when only using flash.
> 
> Should config BLK be updated to include DM_SPI_FLASH?
> Should we explore how to remove BLK as a dependency for EFI_LOADER?

Yes, someone needs to explore how to cleanly make BLK optional for
EFI_LOADER.
diff mbox series

Patch

diff --git a/examples/api/crt0.S b/examples/api/crt0.S
index 57bba9d851..4c23a54b21 100644
--- a/examples/api/crt0.S
+++ b/examples/api/crt0.S
@@ -24,6 +24,21 @@  syscall:
                mtctr     %r11
                bctr

+#elif defined(CONFIG_ARM64)
+
+              .text
+              .globl _start
+_start:
+              ldr           ip0, =search_hint
+              str           sp_el2, [ip0]
+              b             main
+
+
+              .globl syscall
+syscall:
+              ldr           ip0, =syscall_ptr
+              ldr           pc_el2, [ip0]
+
#elif defined(CONFIG_ARM)

               .text