From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id D62F180403 for ; Thu, 16 Mar 2017 05:33:15 -0700 (PDT) Received: by mail-ua0-x235.google.com with SMTP id 72so25115587uaf.3 for ; Thu, 16 Mar 2017 05:33:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=J0Q+9v7pfhIxSj1c7Hg1BR6ucxn5bN4DMTkjFGuwlHU=; b=Zg9jr2v21Sgf/aI/S0vE2WQZx8PGG8BpS3oqqJBAzhXw3ImyvDizGC5qIVTarrmsuE kFETG/W6NdtpA7Yn4jfcETjZEtiY/7o7hTxARxwbtDzBrMuHWpZmMiJsXdl+me81Hrzy +CifA0QuPR6+p9IXNT4nz8G6S4UxZf6YRfT6+mVVjQMBVS4jZmZnjpQ4rdwVXWZjIkXB J5i+6S49BdZIYaWTBddPl0IHjOaRZNenYABF/Y3RONEfGIHUIC9p1iRYZT9R1f5friG/ 9lhnxWOgzdk6UiPzilSsBJTWB3ZqnsiReEXthm12OSmi/Ck0+rxoL0XhThpd4vqE4w5f mGBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=J0Q+9v7pfhIxSj1c7Hg1BR6ucxn5bN4DMTkjFGuwlHU=; b=iVxvzvDkpj6Y0fxBI1NdHLorg2W9a3zrxYS+LUFYb1aHNXKOfKZQ68IJVGplnta01U pTIGKWDKghAh62AxBMMpq2HxIjKOd+mvg7+5toZY4jLmbYR0VZ+StkX2dAyCsBxcXTw2 OD+Z+4TemptB6GMQ+QlBg9gvcdZnaMFgpkgJJEARM7hhU648+aIzfzz5WQgOxgLFDY8d nObkZGJbqL/FetJLdjAE3lv8BK8K5CO3NljjSsxw7WCkJmFdsvig0r1VNNgV5X4nUCvX Rb3HuDZccjyt0UWYXYgyLQS8LqzzhPtVCznSMM1ZuZR64/XY/dKt7/GRA+nlfuD2uPcq qwqQ== X-Gm-Message-State: AFeK/H0Drma7I/h9Sx2+FBYdAWDtLUwYQijl4Jh8HSWrSxbwO0ETfV0tHkORHVE15y8wb6y7EwgMeE9wB3ne4w== X-Received: by 10.159.37.243 with SMTP id 106mr3606900uaf.9.1489667594661; Thu, 16 Mar 2017 05:33:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.171.80 with HTTP; Thu, 16 Mar 2017 05:33:14 -0700 (PDT) In-Reply-To: <7953ce1f-fa7e-e881-ba85-136938fdbd03@redhat.com> References: <426920F0-4266-4BB2-BF19-40715A0F1C01@apple.com> <385c68bb-4a3f-e586-f62b-9dd9f9c6490b@redhat.com> <75A865F3-53E6-4C54-91A0-46A32E3CAB84@apple.com> <7953ce1f-fa7e-e881-ba85-136938fdbd03@redhat.com> From: Michael Zimmermann Date: Thu, 16 Mar 2017 13:33:14 +0100 Message-ID: To: Laszlo Ersek Cc: Andrew Fish , Feng Tian , Liming Gao , "edk2-devel@lists.01.org" , Star Zeng Subject: Re: how to load drivers from additional FV's? X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 12:33:16 -0000 Content-Type: text/plain; charset=UTF-8 Laszlo, I don't know if I was clear enough but I've been able to load drivers from a nested FV without any manual loading or decompressing and without any changes to my code. All I needed to do was putting this into FVMAIN: FILE FV_IMAGE = $(GUID) { SECTION FV_IMAGE = FVMAINPLATFORM } Thanks Michael On Thu, Mar 16, 2017 at 1:27 PM, Laszlo Ersek wrote: > On 03/16/17 13:20, Michael Zimmermann wrote: >> So if I understand this correctly there's no bug to fix because >> nested, uncompressed FV's are already supported > > I'm not sure how to answer this; I guess the answer depends on what > meaning you attribute to "supported". In OVMF it works, but it depends > on two things: OVMF's SEC driver having access to writeable RAM, and > OVMF manually messing with the firmware volumes (locating them, > decompressing the outer file, moving stuff around, and so on). > > On a physical platform, I guess you can do the same, if you are willing > to mess with the FVs manually, and you delay that code until at least > the PEI phase sees the permanent RAM installed. > > Thanks > Laszlo > >> and using compressed >> ones is bad practice anyway? >> >> Thanks >> Michael >> >> On Thu, Mar 16, 2017 at 12:20 PM, Laszlo Ersek wrote: >>> On 03/15/17 16:54, Andrew Fish wrote: >>>> >>>>> On Mar 15, 2017, at 8:38 AM, Laszlo Ersek >>>> > wrote: >>>>> >>>>> On 03/15/17 16:13, Andrew Fish wrote: >>>>>> >>>>>>> On Mar 15, 2017, at 8:07 AM, Laszlo Ersek >>>>>> > wrote: >>>>>>> >>>>>>> On 03/15/17 13:23, Michael Zimmermann wrote: >>>>>>>> I'm trying to add another FV section FVMAIN_COMPACT so I can keep >>>>>>>> Platform specific drivers in a separate, included fdf. >>>>>>>> >>>>>>>> I did this: >>>>>>>> FILE FV_IMAGE = 9E21FD93-9C72-4c15-8C4B-E77F1DB2D792 { >>>>>>>> SECTION GUIDED EE4E5898-3914-4259-9D6E-DC7BD79403CF >>>>>>>> PROCESSING_REQUIRED = TRUE { >>>>>>>> SECTION FV_IMAGE = FVMAIN >>>>>>>> SECTION FV_IMAGE = FVMAINPLATFORM >>>>>>>> } >>>>>>>> } >>>>>>>> >>>>>>>> The image builds file and using uefitool I can verify that the new FV >>>>>>>> is inside the compressed section. >>>>>>>> But none of the drivers gets discovered/loaded and I get 'Protocol not >>>>>>>> present!!' errors. >>>>>>> >>>>>>> The FVs need to be exposed to the DXE core via FV HOBs. See >>>>>>> - 9.8.5 "Firmware Volume HOBs" in Volume 2 of the Platform Init 1.5 >>>>>>> spec, >>>>>>> - and more importantly, 5.7 "Firmware Volume HOB" in Volume 3 of the >>>>>>> same. >>>>>>> >>>>>>> You can use the BuildFvHob() function for this. >>>>>>> >>>>>>> If the firmware volume contains PEIMs (... as well), then it has to be >>>>>>> exposed to the PEI core too, I think. I think the >>>>>>> PeiServicesInstallFvInfoPpi() function can be used for that. (See 3.3 >>>>>>> "PEI" in Volume 3 of the PI spec.) >>>>>>> >>>>>>> ... I used the PeiFvInitialization() function in >>>>>>> OvmfPkg/PlatformPei/Fv.c as a "cheat sheet" for the above. >>>>>>> >>>>>> >>>>>> Laszlo, >>>>>> >>>>>> I think this case is an FV that is compressed and nested in another >>>>>> FV that is discovered. I think the issues is multiple FV Sections in >>>>>> an FV file are not currently supported. >>>>> >>>>> In OVMF we do the same: >>>>> >>>>> FILE FV_IMAGE = 9E21FD93-9C72-4c15-8C4B-E77F1DB2D792 { >>>>> SECTION GUIDED EE4E5898-3914-4259-9D6E-DC7BD79403CF >>>>> PROCESSING_REQUIRED = TRUE { >>>>> # >>>>> # These firmware volumes will have files placed in them uncompressed, >>>>> # and then both firmware volumes will be compressed in a single >>>>> # compression operation in order to achieve better overall >>>>> compression. >>>>> # >>>>> SECTION FV_IMAGE = PEIFV >>>>> SECTION FV_IMAGE = DXEFV >>>>> } >>>>> } >>>>> >>>>> "OvmfPkg/Sec/SecMain.c" decompresses the compressed FFS file into >>>>> memory -- which is special to OVMF, i.e. the fact that there is >>>>> writeable memory in SEC --, then jumps to the PEI entry point. >>>>> PlatformPei then exposes DXEFV to the PEI core (for loading the DXE >>>>> core AIUI) and to the DXE core as well (for loading DXE modules). >>>>> >>>>> The multiple FV sections in the FFS file are not discovered >>>>> automatically. First, the OVMF build process saves the final (= >>>>> decompressed) in-memory locations of the nested FVs into PCDs. Second, >>>>> in DecompressMemFvs(), the SEC module decompresses the outer, >>>>> compressed, FFS file, then locates the embedded FVs manually with >>>>> FindFfsSectionInstance(), then moves the decompressed FVs individually >>>>> to their pre-recorded locations. >>>>> >>>>> In Michael's case, I think the same should be possible -- since FVMAIN >>>>> is running for him, the outer, compressed file must already be >>>>> decompressed (in full) to some temporary buffer in memory. If he can >>>>> find, manually, the second section (with the embedded FVMAINPLATFORM >>>>> firmware volume in it) in that area, then he can also expose it to the >>>>> DXE core, I believe. >>>>> >>>> >>>> Laszlo, >>>> >>>> The DXE Core will dispatch FVs with Depex "automagically" but only one >>>> FV_IMAGE Section per FV_IMAGE file. >>>> >>>> So one workaround would be to add a 2nd FV_IMAGE file that contains the >>>> 2nd FV in the 1st FV_IMAGE Section. >>>> >>>> Also I'm not sure if the outer FV is compressed, but compressing >>>> compressed data usually does not end well as the algorithms leverage >>>> entropy. >>> >>> I apologize if my previous emails were confusing; I didn't mean to imply >>> nested compression. OVMF doesn't do that. >>> >>>> It is better to just compress the outer FV and have everything >>>> else uncompressed and let it all get compressed together. >>> >>> Yes, that's what OVMF does. >>> >>> Did you perhaps misread the comment above that I quoted from the FDF? >>> >>> "These firmware volumes will have files placed in them *uncompressed*, >>> and then both firmware volumes will be compressed in a single >>> compression operation in order to achieve better overall compression." >>> >>> (Emphasis mine.) >>> >>> Thanks! >>> Laszlo >>> >>>> This also >>>> helps as there will be common dictionary entries so compressing as much >>>> data as possible in one shot usually works better. So for example if the >>>> outer FV is compressed it may have a dictionary entry that represents >>>> CopyMem, and it can represent that pattern with a small number of bits. >>>> Doing compression multiple times causes duplication as each compressed >>>> image has one copy of CopyMem (massive over simplification). Also if you >>>> compress a nested FV then the CopyMem pattern does not exist in the >>>> compressed data, and since the compressed data is more random it is hard >>>> to find patterns to compress, so it hurts the compression of the outer FV. >>>> >>>> Thanks, >>>> >>>> Andrew Fish >>>> >>>>> Thanks >>>>> Laszlo >>>>> _______________________________________________ >>>>> edk2-devel mailing list >>>>> edk2-devel@lists.01.org >>>>> https://lists.01.org/mailman/listinfo/edk2-devel >>>> >>> >