public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Loh, Tien Hock" <tien.hock.loh@intel.com>
To: "Gao, Liming" <liming.gao@intel.com>,
	"devel@edk2.groups.io" <devel@edk2.groups.io>,
	"lersek@redhat.com" <lersek@redhat.com>
Cc: "leif.lindholm@linaro.org" <leif.lindholm@linaro.org>,
	"ard.biesheuvel@linaro.org" <ard.biesheuvel@linaro.org>
Subject: Re: [edk2-devel] Problem with decompression on EDK2
Date: Fri, 27 Sep 2019 07:04:42 +0000	[thread overview]
Message-ID: <EF88013823EA1B42AC7142BA7DA05E0634CF14AB@PGSMSX110.gar.corp.intel.com> (raw)
In-Reply-To: <4A89E2EF3DFEDB4C8BFDE51014F606A14E502303@SHSMSX104.ccr.corp.intel.com>

[-- Attachment #1: Type: text/plain, Size: 3803 bytes --]

Hi Liming,

I've tested another workaround - Move the FD file to a higher RAM location (originally, it is loaded into 0x50000, now it is at 0x10000000)
With the FD file moved to 0x10000000, the decompression works every time, even with bigger FD. I've attached the my FD file in the mail. 

Thanks
Tien Hock

> -----Original Message-----
> From: Gao, Liming <liming.gao@intel.com>
> Sent: Friday, September 27, 2019 8:13 AM
> To: devel@edk2.groups.io; lersek@redhat.com; Loh, Tien Hock
> <tien.hock.loh@intel.com>
> Cc: leif.lindholm@linaro.org; ard.biesheuvel@linaro.org
> Subject: RE: [edk2-devel] Problem with decompression on EDK2
> 
> Can you share the generated FD image? I can help check whether it is
> generated correctly with compression.
> 
> Thanks
> Liming
> 
> >-----Original Message-----
> >From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> >Laszlo Ersek
> >Sent: Friday, September 27, 2019 3:22 AM
> >To: devel@edk2.groups.io; Loh, Tien Hock <tien.hock.loh@intel.com>
> >Cc: leif.lindholm@linaro.org; ard.biesheuvel@linaro.org
> >Subject: Re: [edk2-devel] Problem with decompression on EDK2
> >
> >On 09/26/19 11:27, Loh, Tien Hock wrote:
> >> Hi
> >>
> >> I have an issue while porting a new platform to EDK2. After porting
> >> the
> >Stratix 10 platform (ARM) to EDK2 it works correctly. However, when I
> >tried to add more INF to the FDF file, it failed to decompress the
> >image during boot time, log as below
> >> INFO:    DDR: DRAM calibration success.
> >> INFO:    Scrubbing ECC
> >> INFO:    Init HPS NOC's DDR Scheduler.
> >> NOTICE:  BL2: v2.1(debug):v2.1-15-g5880144-dirty
> >> NOTICE:  BL2: Built : 14:02:01, Aug 22 2019
> >> INFO:    BL2: Doing platform setup
> >> INFO:    BL2: Loading image id 3
> >> INFO:    Loading image id=3 at address 0xffe1c000
> >> INFO:    Image id=3 loaded: 0xffe1c000 - 0xffe22019
> >> INFO:    BL2: Loading image id 5
> >> INFO:    Loading image id=5 at address 0x50000
> >> INFO:    Image id=5 loaded: 0x50000 - 0x150000
> >> NOTICE:  BL2: Booting BL31
> >> INFO:    Entry point address = 0xffe1c000
> >> INFO:    SPSR = 0x3cd
> >> NOTICE:  BL31: v2.1(release):v2.1-604-g3441952
> >> NOTICE:  BL31: Built : 15:32:55, Sep 25 2019 UEFI firmware (version
> >> 1.0 built at 15:15:26 on Sep 26 2019) Decompress Failed - Invalid
> >> Parameter
> >>
> >> ASSERT_EFI_ERROR (Status = Not Found) ASSERT
> >> [ArmPlatformPrePiUniCore]
> >/nfs/png/disks/swuser_work_thloh/push/build/edk2/ArmPlatformPkg/PreP
> i
> >/PrePi.c(151): !EFI_ERROR (Status)
> >>
> >> This happens if I add more items to the image, and if I reduce the
> >> size of the
> >image, it works correctly again. This could be a clue to what could've
> >gone wrong. Does anyone have any ideas what might've gone wrong?
> >> I traced the decompression to LzmaDecode, and got lost in the code there.
> >
> >The compressed section in a firmware volume is likely truncated at
> >build time, and does not decompress at boot time. I would expect the
> "build"
> >utility to report this issue, and stop with an error.
> >
> >When you run "build" in the successful and in the failing cases, what
> >are the stats, respectively, that are printed at the end of the build logs?
> >
> >Also, you could check your FDF file(s) near
> >"EE4E5898-3914-4259-9D6E-DC7BD79403CF"; perhaps you find interesting
> bits.
> >
> >Furthermore, if the boundary seems to be 16MB, then it could be an
> >issue in the processing code. See "ExtendedSize" in
> >"MdePkg/Include/Pi/PiFirmwareFile.h". I vaguely recall issues around
> >some code trying to parse EFI_FFS_FILE_HEADER2 as EFI_FFS_FILE_HEADER,
> >or EFI_COMMON_SECTION_HEADER2 as EFI_COMMON_SECTION_HEADER.
> >
> >Thanks
> >Laszlo
> >
> >


[-- Attachment #2: INTELSTRATIX10_EFI.fd --]
[-- Type: application/octet-stream, Size: 1048576 bytes --]

  reply	other threads:[~2019-09-27  7:05 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-26  9:27 Problem with decompression on EDK2 Loh, Tien Hock
2019-09-26 19:22 ` [edk2-devel] " Laszlo Ersek
2019-09-27  0:13   ` Liming Gao
2019-09-27  7:04     ` Loh, Tien Hock [this message]
2019-09-29  7:06       ` Liming Gao
2019-10-01  2:33         ` Loh, Tien Hock
2019-10-08 14:03           ` Liming Gao
2019-10-08 16:11             ` Loh, Tien Hock

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=EF88013823EA1B42AC7142BA7DA05E0634CF14AB@PGSMSX110.gar.corp.intel.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox