[U-Boot,11/11] efi_loader: exclude openrd devices

Message ID 20171010122309.25313-12-robdclark@gmail.com
State New
Delegated to: Alexander Graf
Headers show
Series
  • efi_loader: patches for Shell.efi
Related show

Commit Message

Rob Clark Oct. 10, 2017, 12:23 p.m.
These devices have small image size limits, so exclude EFI_LOADER to
help avoid exceeding limits.

Signed-off-by: Rob Clark <robdclark@gmail.com>
---
 lib/efi_loader/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Heinrich Schuchardt Oct. 10, 2017, 10:28 p.m. | #1
On 10/10/2017 02:23 PM, Rob Clark wrote:
> These devices have small image size limits, so exclude EFI_LOADER to
> help avoid exceeding limits.
> 
> Signed-off-by: Rob Clark <robdclark@gmail.com>
> ---
>   lib/efi_loader/Kconfig | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> index d2b6327119..6e22940da5 100644
> --- a/lib/efi_loader/Kconfig
> +++ b/lib/efi_loader/Kconfig
> @@ -1,6 +1,6 @@
>   config EFI_LOADER
>   	bool "Support running EFI Applications in U-Boot"
> -	depends on (ARM || X86) && OF_LIBFDT
> +	depends on (ARM || X86) && OF_LIBFDT && !TARGET_OPENRD
>   	default y
>   	help
>   	  Select this option if you want to run EFI applications (like grub2)
> 

I understand that with the progress we make on EFI implementation and 
other parts of U-Boot the U-Boot image size is growing too big for 
direct loading by the primary boot loader.

The OPENRD boards have abundant memory, e.g. openrd_ultimate_defconfig 
refers to a board with 512 MB RAM.

So I think completely disabling EFI is not the solution.
Instead building an SPL should be enabled for this architecture when the 
image is becoming too big for direct load.

I am copying in the KIRKWOOD maintainers go get their view.

Best regards

Heinrich
Rob Clark Oct. 10, 2017, 10:50 p.m. | #2
On Tue, Oct 10, 2017 at 6:28 PM, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
> On 10/10/2017 02:23 PM, Rob Clark wrote:
>>
>> These devices have small image size limits, so exclude EFI_LOADER to
>> help avoid exceeding limits.
>>
>> Signed-off-by: Rob Clark <robdclark@gmail.com>
>> ---
>>   lib/efi_loader/Kconfig | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
>> index d2b6327119..6e22940da5 100644
>> --- a/lib/efi_loader/Kconfig
>> +++ b/lib/efi_loader/Kconfig
>> @@ -1,6 +1,6 @@
>>   config EFI_LOADER
>>         bool "Support running EFI Applications in U-Boot"
>> -       depends on (ARM || X86) && OF_LIBFDT
>> +       depends on (ARM || X86) && OF_LIBFDT && !TARGET_OPENRD
>>         default y
>>         help
>>           Select this option if you want to run EFI applications (like
>> grub2)
>>
>
> I understand that with the progress we make on EFI implementation and other
> parts of U-Boot the U-Boot image size is growing too big for direct loading
> by the primary boot loader.
>
> The OPENRD boards have abundant memory, e.g. openrd_ultimate_defconfig
> refers to a board with 512 MB RAM.
>
> So I think completely disabling EFI is not the solution.
> Instead building an SPL should be enabled for this architecture when the
> image is becoming too big for direct load.
>
> I am copying in the KIRKWOOD maintainers go get their view.
>

I'm defn open to alternatives..  I don't know too much about what the
limit was on these boards, other than we were close to it before, and
the additional uefi proto's add <4k to the image size, which was
enough to push it over the limit.  Since this was effecting only a few
boards, I went with this.. if it is only a temporary fix that can be
removed soon, or if someone can do something better with a separate
SPL build in the near term, that would be great.

BR,
-R
Stefan Roese Oct. 11, 2017, 7:07 a.m. | #3
(Adding Albert as maintainer again)

On 11.10.2017 00:50, Rob Clark wrote:
> On Tue, Oct 10, 2017 at 6:28 PM, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>> On 10/10/2017 02:23 PM, Rob Clark wrote:
>>>
>>> These devices have small image size limits, so exclude EFI_LOADER to
>>> help avoid exceeding limits.
>>>
>>> Signed-off-by: Rob Clark <robdclark@gmail.com>
>>> ---
>>>    lib/efi_loader/Kconfig | 2 +-
>>>    1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
>>> index d2b6327119..6e22940da5 100644
>>> --- a/lib/efi_loader/Kconfig
>>> +++ b/lib/efi_loader/Kconfig
>>> @@ -1,6 +1,6 @@
>>>    config EFI_LOADER
>>>          bool "Support running EFI Applications in U-Boot"
>>> -       depends on (ARM || X86) && OF_LIBFDT
>>> +       depends on (ARM || X86) && OF_LIBFDT && !TARGET_OPENRD
>>>          default y
>>>          help
>>>            Select this option if you want to run EFI applications (like
>>> grub2)
>>>
>>
>> I understand that with the progress we make on EFI implementation and other
>> parts of U-Boot the U-Boot image size is growing too big for direct loading
>> by the primary boot loader.
>>
>> The OPENRD boards have abundant memory, e.g. openrd_ultimate_defconfig
>> refers to a board with 512 MB RAM.
>>
>> So I think completely disabling EFI is not the solution.
>> Instead building an SPL should be enabled for this architecture when the
>> image is becoming too big for direct load.
>>
>> I am copying in the KIRKWOOD maintainers go get their view.
>>
> 
> I'm defn open to alternatives..  I don't know too much about what the
> limit was on these boards, other than we were close to it before, and
> the additional uefi proto's add <4k to the image size, which was
> enough to push it over the limit.  Since this was effecting only a few
> boards, I went with this.. if it is only a temporary fix that can be
> removed soon, or if someone can do something better with a separate
> SPL build in the near term, that would be great.

I personally have not used any Kirkwood based platforms in the last few
years (and don't have access to one). And I don't see activities here
from mother developers either. As adding SPL support is not trivial,
frankly I don't see that this will be done anytime soon if at all.

Perhaps the image size can be reduced by removing other features or
interfaces from the OPENRD platform instead (CMD_MII, JFFS2, ...)?

Thanks,
Stefan
Alexander Graf Oct. 11, 2017, 7:22 a.m. | #4
On 11.10.17 09:07, Stefan Roese wrote:
> (Adding Albert as maintainer again)
> 
> On 11.10.2017 00:50, Rob Clark wrote:
>> On Tue, Oct 10, 2017 at 6:28 PM, Heinrich Schuchardt
>> <xypron.glpk@gmx.de> wrote:
>>> On 10/10/2017 02:23 PM, Rob Clark wrote:
>>>>
>>>> These devices have small image size limits, so exclude EFI_LOADER to
>>>> help avoid exceeding limits.
>>>>
>>>> Signed-off-by: Rob Clark <robdclark@gmail.com>
>>>> ---
>>>>    lib/efi_loader/Kconfig | 2 +-
>>>>    1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
>>>> index d2b6327119..6e22940da5 100644
>>>> --- a/lib/efi_loader/Kconfig
>>>> +++ b/lib/efi_loader/Kconfig
>>>> @@ -1,6 +1,6 @@
>>>>    config EFI_LOADER
>>>>          bool "Support running EFI Applications in U-Boot"
>>>> -       depends on (ARM || X86) && OF_LIBFDT
>>>> +       depends on (ARM || X86) && OF_LIBFDT && !TARGET_OPENRD
>>>>          default y
>>>>          help
>>>>            Select this option if you want to run EFI applications (like
>>>> grub2)
>>>>
>>>
>>> I understand that with the progress we make on EFI implementation and
>>> other
>>> parts of U-Boot the U-Boot image size is growing too big for direct
>>> loading
>>> by the primary boot loader.
>>>
>>> The OPENRD boards have abundant memory, e.g. openrd_ultimate_defconfig
>>> refers to a board with 512 MB RAM.
>>>
>>> So I think completely disabling EFI is not the solution.
>>> Instead building an SPL should be enabled for this architecture when the
>>> image is becoming too big for direct load.
>>>
>>> I am copying in the KIRKWOOD maintainers go get their view.
>>>
>>
>> I'm defn open to alternatives..  I don't know too much about what the
>> limit was on these boards, other than we were close to it before, and
>> the additional uefi proto's add <4k to the image size, which was
>> enough to push it over the limit.  Since this was effecting only a few
>> boards, I went with this.. if it is only a temporary fix that can be
>> removed soon, or if someone can do something better with a separate
>> SPL build in the near term, that would be great.
> 
> I personally have not used any Kirkwood based platforms in the last few
> years (and don't have access to one). And I don't see activities here
> from mother developers either. As adding SPL support is not trivial,
> frankly I don't see that this will be done anytime soon if at all.
> 
> Perhaps the image size can be reduced by removing other features or
> interfaces from the OPENRD platform instead (CMD_MII, JFFS2, ...)?

If it's too much work to make EFI_LOADER work on these platforms, I
guess it's ok to disable it just for them. Given how dated they are,
chances are pretty slim that enabling EFI_LOADER by default will give us
a U-Boot copy on the device that supports it straight from the factory ;).

However, I would ideally prefer to see that happen in the respective
defconfigs, not in Kconfig.


Alex

Patch

diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index d2b6327119..6e22940da5 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -1,6 +1,6 @@ 
 config EFI_LOADER
 	bool "Support running EFI Applications in U-Boot"
-	depends on (ARM || X86) && OF_LIBFDT
+	depends on (ARM || X86) && OF_LIBFDT && !TARGET_OPENRD
 	default y
 	help
 	  Select this option if you want to run EFI applications (like grub2)