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

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

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

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

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?

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?

在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

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.

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.

On Sun, Jun 02, 2024 at 12:16:38AM +0000, Brunham, Kalen wrote:

Thanks Tom.

Can you suggest who is the existing owner of this code I could work with?

You should CC Heinrich for sure once you have things working.

-----Original Message----- From: Tom Rini trini@konsulko.com Sent: Friday, May 31, 2024 12:03 PM To: Brunham, Kalen kalen.brunham@intel.com Cc: Jiaxun Yang jiaxun.yang@flygoat.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 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.

-- Tom

On 6/4/24 05:34, Brunham, Kalen wrote:

Hi Tom/Heinrich,

I have https://github.com/u-boot/u-boot/pull/574 that has a proposed change. It is currently failing clang sandbox, which looks a little strange and I'm looking into it. Please let me know if you have any feedback on the general strategy.

Thanks, -Kalen

-----Original Message----- From: Tom Rini trini@konsulko.com Sent: Monday, June 3, 2024 1:23 PM To: Brunham, Kalen kalen.brunham@intel.com Cc: Jiaxun Yang jiaxun.yang@flygoat.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 Sun, Jun 02, 2024 at 12:16:38AM +0000, Brunham, Kalen wrote:

...

Thanks Tom.

Can you suggest who is the existing owner of this code I could work with?

You should CC Heinrich for sure once you have things working.

...

-----Original Message----- From: Tom Rini trini@konsulko.com Sent: Friday, May 31, 2024 12:03 PM To: Brunham, Kalen kalen.brunham@intel.com Cc: Jiaxun Yang jiaxun.yang@flygoat.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 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.

EFI applications like iPXE provide block devices. CONFIG_BLK does not depend on anything but CONFIG_DM.

Why would you prefer to make BLK optional for EFI_LOADER?

Best regards

Heinrich