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-
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
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

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)
  - Assume user to apply dpl manually by " fsl_mc apply DPL" before running 

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.


U-Boot mailing list

Reply via email to