Re: [edk2-devel] Problem with decompression on EDK2

["Loh, Tien Hock" <tien.hock.loh@intel.com>]

Hi Liming,

Thanks for the quick response.
Can you help show me where I can find more information on the decompression (ie. how to test the image, etc.)?

Thanks
Tien Hock

> -----Original Message-----
> From: Gao, Liming <liming.gao@intel.com>
> Sent: Sunday, September 29, 2019 3:06 PM
> To: Loh, Tien Hock <tien.hock.loh@intel.com>; devel@edk2.groups.io;
> lersek@redhat.com
> Cc: leif.lindholm@linaro.org; ard.biesheuvel@linaro.org
> Subject: RE: [edk2-devel] Problem with decompression on EDK2
> 
> Tien Hock:
>   The image is correct. It can be decompressed by lzma.
>   When FD is loaded into 0x50000, I suspect that the image data can't fully
> read. Then, the decompress will failure.
> 
>   FD image last valid byte offset is 0xC1B8F. Its value is 0x83. When FD base
> address is 0x50000, this position is 0x111B8F.
>   You can read this place and check its value.
> 
> Thanks
> Liming
> >-----Original Message-----
> >From: Loh, Tien Hock
> >Sent: Friday, September 27, 2019 3:05 PM
> >To: Gao, Liming <liming.gao@intel.com>; devel@edk2.groups.io;
> >lersek@redhat.com
> >Cc: leif.lindholm@linaro.org; ard.biesheuvel@linaro.org
> >Subject: RE: [edk2-devel] Problem with decompression on EDK2
> >
> >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/Pr
> >eP
> >> 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
> >> >
> >> >