[U-Boot] [PATCH v5 1/7] ls2080: Exit dpaa only right before exiting U-Boot

[Alexander Graf <agraf@suse.de>]

On 10/17/2016 10:56 AM, Prabhakar Kushwaha wrote:
>> -----Original Message-----
>> From: Alexander Graf [mailto:agraf at suse.de]
>> Sent: Monday, October 17, 2016 12:28 PM
>> To: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; u-
>> boot at lists.denx.de
>> Cc: york sun <york.sun@nxp.com>
>> Subject: Re: [PATCH v5 1/7] ls2080: Exit dpaa only right before exiting U-Boot
>>
>> Hi Prabhakara,
>>
>> On 17.10.16 05:42, Prabhakar Kushwaha wrote:
>>> Hi Alex,
>>>
>>>> -----Original Message-----
>>>> From: Alexander Graf [mailto:agraf at suse.de]
>>>> Sent: Saturday, October 15, 2016 3:33 PM
>>>> To: u-boot at lists.denx.de
>>>> Cc: york sun <york.sun@nxp.com>; Prabhakar Kushwaha
>>>> <prabhakar.kushwaha@nxp.com>
>>>> Subject: [PATCH v5 1/7] ls2080: Exit dpaa only right before exiting U-Boot
>>>>
>>>> On ls2080 we have a separate network fabric component which we need to
>>>> shut down before we enter Linux (or any other OS). Along with that also
>>>> comes configuration of the fabric using a description file.
>>>>
>>>> Today we always stop and configure the fabric in the boot script and
>>>> (again) exit it on device tree generation. This works ok for the normal
>>>> booti case, but with bootefi the payload we're running may still want to
>>>> access the network.
>>>>
>>>> So let's add a new fsl_mc command that defers configuration and stopping
>>>> the hardware to when we actually exit U-Boot, so that we can still use
>>>> the fabric from an EFI payload.
>>>>
>>>> For existing boot scripts, nothing should change with this patch.
>>>>
>>>> Signed-off-by: Alexander Graf <agraf@suse.de>
>>>>
>>> Can we get one small modification in this patch to include env variable.
>>> So if a user **always** want " lazyapply", this info can be stored in env
>> variable. This env variable will be used after reset without explicit u-boot
>> command.
>>
>> I'm not sure I understand your suggestion. We use "lazyapply" because
>> EFI payloads need to be able to use the fabric for network I/O which is
>> impossible after a normal apply.
>>
>> Because we don't know in bootcmd whether we will end up in the old bootm
>> path or in the fallback distro path (which again potentially means
>> efi_loader), we have to play safe (lazyapply) by default.
>>
> If I understand correctly, this patch defines a variable mc_lazy_dpl_addr.  It is set via " fsl_mc lazyapply DPL" u-boot command.
> If this variable set
>    - Apply DPL file during bootm (no user intervention)
> Else
>   - Assume user to apply dpl manually by " fsl_mc apply DPL" before running bootm.
>
> One modification can be done to store value mc_lazy_dpl_addr in env so that " fsl_mc lazyapply DPL " will not be required to run after every reset.

Ah, I see what you're getting at. I like the idea, but I'm not sure this 
is what users would expect. So imagine you do

   # fsl_mc lazyapply ...
   # <attempt boot, fails>
   # <modify environment for next time
   # saveenv

then suddenly you have the lazyapply in your environment. In *most* 
parts of U-Boot environment variables are not used for state transfer 
(one function sets it, another one reads it). So having it here would be 
pretty unnatural and potentially confusing to users.

I'd leave the decision up to York though, it's his command :). Changing 
it to be env based instead is trivial.


Alex