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:ag...@suse.de]
>>> Sent: Monday, October 17, 2016 12:28 PM
>>> To: Prabhakar Kushwaha <prabhakar.kushw...@nxp.com>; u-
>>> b...@lists.denx.de
>>> Cc: york sun <york....@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:ag...@suse.de]
>>>>> Sent: Saturday, October 15, 2016 3:33 PM
>>>>> To: u-boot@lists.denx.de
>>>>> Cc: york sun <york....@nxp.com>; Prabhakar Kushwaha
>>>>> <prabhakar.kushw...@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 <ag...@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.

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.


U-Boot mailing list

Reply via email to