From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::231]) (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 7F5B680401 for ; Thu, 16 Mar 2017 05:20:40 -0700 (PDT) Received: by mail-ua0-x231.google.com with SMTP id 72so24927391uaf.3 for ; Thu, 16 Mar 2017 05:20:40 -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=XoU66aLoMsXw2vb/9CN253vKWDKGMwY+U+EKTwz/6Co=; b=Qxg79eUzVvLCw55pek7tIKZh4TYgoGM+2x6lZM6FNx4HD1fdKgxrvRzHgZvoCyO9Vg bnLZYlu3K9gAASj3ArG8W8WhYUTo49wiNRsh2obCYzk9aXiUomNikV7ljPKdlyUsuFUq wtqWjuDicltGgGrKaC1wrivFYkZB3UK1fJbBpelDjwmEWYZMANXH3hTWl8AaK2gTqOwT q1jfeLeTPNhA3wTNhHi15P8xpWmrusEld/rMD3EQb8sQIcm6g85Q7CXHnJQhz1zolX6g JFOIh27l7czFZ/NYscZFtcvygqBIhsW4pknJQIagmlMRKDTrwS1KOrOrGNuv5gWP2be7 O2gg== 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=XoU66aLoMsXw2vb/9CN253vKWDKGMwY+U+EKTwz/6Co=; b=YEqm4uVA0p4wBTGht0CJFl8XkSSKbax5wDln2I405Ekcry2y4ehmxHiuliVUtr9JRT EGj8n9K9Q+l+XjOlucvje5ERafx8YceCyAJncxjsKazCMIagsWqBMek9boLfE1EFcl+T XuuPLx5Gnm+AmsMC0TZosNf48tc6qat05VuE2ZgJGLv2A7E6edXW++U4KjvdqbdMGnvH fZ9X8OEJ155pgER4uyP3OOj4yp5gZ2zO60CqzoVG1sSaSUf1Kx/foPUNQ8cXvpYO4LHh pU7IxBfxEDJDnbPm282Fp2JlIjRO/LOAcBOq5C4ZYrvJgaPXf3rXBBM3zhIjgT23qOEx vbNg== X-Gm-Message-State: AFeK/H2+12q9NLeTfco2d0j7do0hc75ygtmoxEEajSxBn3rP++tHy675PJKaipFvtwWV218MCTA01wuB3R2Ojg== X-Received: by 10.176.94.3 with SMTP id z3mr3168238uag.145.1489666838857; Thu, 16 Mar 2017 05:20:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.171.80 with HTTP; Thu, 16 Mar 2017 05:20:38 -0700 (PDT) In-Reply-To: References: <426920F0-4266-4BB2-BF19-40715A0F1C01@apple.com> <385c68bb-4a3f-e586-f62b-9dd9f9c6490b@redhat.com> <75A865F3-53E6-4C54-91A0-46A32E3CAB84@apple.com> From: Michael Zimmermann Date: Thu, 16 Mar 2017 13:20:38 +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:20:40 -0000 Content-Type: text/plain; charset=UTF-8 So if I understand this correctly there's no bug to fix because nested, uncompressed FV's are already supported 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 >> >