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. > 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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
