Would you please help to file a bugzillar for tracking purpose? Thank you Yao Jiewen From: wang xiaofeng [mailto:winggundum82@163.com] Sent: Sunday, February 12, 2017 8:46 PM To: Yao, Jiewen Cc: edk2-devel@lists.01.org Subject: Re:Re: [edk2] CapsuleApp behavior for CAPSULE_FLAGS_PERSIST_ACROSS_RESET only capsule Hi Jiewen, Thanks ! I believe ¨CNR flag will be helpful to me. At 2017-02-13 11:52:50, "Yao, Jiewen" > wrote: >I see your point. > > >1) That is possible. To make the solution complete, I am thinking to add ¨CNR (no-reset) flag. > >2) If you just want to update multiple capsules at one time, current APP already support this feature. >You may use: >CapsuleApp Bios.Cap Me.Cap Bmc.Cap > >Thank you >Yao Jiewen > >From: wang xiaofeng [mailto:winggundum82@163.com] >Sent: Sunday, February 12, 2017 6:10 PM >To: Yao, Jiewen > >Cc: edk2-devel@lists.01.org >Subject: Re:Re: [edk2] CapsuleApp behavior for CAPSULE_FLAGS_PERSIST_ACROSS_RESET only capsule > >Hi Jiewen, > Sorry, I forgot that I modified Capsuleapp before, Trunk Caspuleapp behavior is like you said" If a capsule has CAPSULE_FLAGS_PERSIST_ACROSS_RESET, capsule app will trigger reset". The logic doesn;t have errors. >But the behavior is a little different from my understanding . Could you think if we can change the behavior to " If a capsule has CAPSULE_FLAGS_PERSIST_ACROSS_RESET, capsule app will NOT trigger reset,let user trigger the reset later"? >The reasons are as the followings: >1) user cannot distinguish whether the reset is triggered by bios code or application code , there is no difference for CAPSULE_FLAGS_PERSIST_ACROSS_RESET only capsule and CAPSULE_FLAGS_PERSIST_ACROSS_RESET + CAPSULE_FLAGS_INITIATE_RESET capsule in current design >2) user may have to update bios capsule , ME capsule ,BMC capsule together,otherwise system cannot work in next reboot. So after bios capsule update done , a reset is not expected. User want to update it later after all capsule are updated. > >Anyhow , this is a new feature request and you can decide whether need to add this feature. > > > > > > >At 2017-02-10 19:24:55, "Yao, Jiewen" >> wrote: > >>That is an interesting question. > >> > >>A general rule for Capsule App is: > >> > >>1) If a capsule has CAPSULE_FLAGS_INITIATE_RESET, the CapsuleService will issue reset. No need to handler in CapsuleApp. (The free memory logic will not run) > >> > >>2) If a capsule has CAPSULE_FLAGS_PERSIST_ACROSS_RESET, the CapsuleService will not issue reset, because CapsuleService will let caller decide when to reset. So here CapsuleApp does reset. (The free memory logic will not run) > >> > >>3) If a capsule has no CAPSULE_FLAGS_PERSIST_ACROSS_RESET flag, the CapsuleService processes the image immediately. Then CapsuleApp can free the buffer finally, because it is already processed. > >> > >>May I know where you think we have logic error? > >> > >>Thank you > >>Yao Jiewen > >> > >>From: wang xiaofeng [mailto:winggundum82@163.com] > >>Sent: Friday, February 10, 2017 1:27 AM > >>To: Yao, Jiewen >>; edk2-devel@lists.01.org> > >>Subject: CapsuleApp behavior for CAPSULE_FLAGS_PERSIST_ACROSS_RESET only capsule > >> > >>Hi Jiewen, > >> I think it might be a logic error for CapsuleApp with CAPSULE_FLAGS_PERSIST_ACROSS_RESET only capsule. If a capsule only have CAPSULE_FLAGS_PERSIST_ACROSS_RESET flag, my understanding it will not trigger reset automatially. User will trigger resetŁ¨S3) in OS or application like CapsuleApp. > >> CapsuleApp will not trigger reset if CAPSULE_FLAGS_INITIATE_RESET is not set, the problem is it will free the capsule buffer also! > >> > >>Done: > >> for (Index = 0; Index < CapsuleNum; Index++) { > >> if (CapsuleBuffer[Index] != NULL) { > >> FreePool (CapsuleBuffer[Index]); > >> } > >> } > >> > >> CleanGatherList(BlockDescriptors, CapsuleNum); > >> > >> I trited to remove the above free buffer logic and capsuleApp can work with CAPSULE_FLAGS_INITIATE_RESET only attribute. The capsule data should be kept in this case > >> > >> > >> > >> > >> > >>_______________________________________________ > >>edk2-devel mailing list > >>edk2-devel@lists.01.org> > >>https://lists.01.org/mailman/listinfo/edk2-devel > > >