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

[york sun]

On 10/17/2016 04:45 AM, Alexander Graf wrote:
>
>
> 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 at nxp.com>; u-
>>> boot at lists.denx.de
>>> Cc: york sun <york.sun at 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 at nxp.com>; Prabhakar Kushwaha
>>>>> <prabhakar.kushwaha at 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 at 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.
>
Prabhakar,

I believe you are trying to address another related issue for applying 
DPL. Please submit a patch on top of Alex's. You can wait a little bit 
after his set is settled.

York