[U-Boot] [PATCH v2 0/4] Add FreeBSD kconfig options

[Alexander Graf]

On 17/01/2017 20:57, Warner Losh wrote:
> On Tue, Jan 17, 2017 at 12:47 PM, Emmanuel Vadot <manu at bidouilliste.com> wrote:
>>
>>  Hi Alexander,
>>
>> On Tue, 17 Jan 2017 20:36:59 +0100
>> Alexander Graf <agraf at suse.de> wrote:
>>
>>>
>>>
>>> On 17/01/2017 16:50, Emmanuel Vadot wrote:
>>>> This series of patches add the needed bits for booting the FreeBSD
>>>> loader and kernel.
>>>> FreeBSD loader and kernel needs the U-Boot API and dcache/icache flushed
>>>> for it to run so add this operation in go/bootelf command and when closing
>>>> the API.
>>>> Also add some some boot command that locate and run the FreeBSD loader
>>>> if found.
>>>
>>> Is there any particular reason the EFI boot path doesn't work for you?
>>>
>>> Configuring u-boot differently to be able to boot FreeBSD sounds a bit
>>> strange to me.
>>>
>>>
>>> Alex
>>
>>  EFI works fine for us, that's what we use for arm64 (pine64/rpi3 for
>> example) because we want to only use EFI for arm64.
>>  For armv6/v7 we have legacy devices etc ... and even if EFI works
>> (well honestly I have to fix our smbios code for it to work properly)
>> we need to be able to boot without EFI support.
>>  With this series of patches is an EFI binary is found this is the one
>> that would be loaded, so when the times comes we could make our
>> releases with EFI bootloaders for ARM. In the meantimes we still need
>> the U-Boot API for our loader.
>
> In addition, we have a long-term support branch (FreeBSD 11.x) that we
> need to support with the current setup since we use u-boot to load our
> tertiary loader which loads the kernel and related files (hence the
> need for the u-boot app API). It's something that's evolved over a
> number of years without proper upstreaming in the past. This series of
> patches lets us continue to use the tried and true paths, as well as
> setting the stage for a migration to EFI for the next major supported
> branch of FreeBSD (12.x, not due for a release for about a year or
> so). FreeBSD 11 support needs to continue past FreeBSD 12's release.
> Finally, as Emmanuel has said, there's still some rough edges to
> FreeBSD/arm's EFI support that need to be worked through in parallel
> before people will switch to the new way.

Thanks a lot to both of you for the detailed description. That indeed 
makes a lot of sense altogether.


Alex