Ok, noted with thanks Liming. I'll try the tools out. Thanks Tien Hock
> -----Original Message----- > From: Gao, Liming <liming....@intel.com> > Sent: Tuesday, October 8, 2019 10:04 PM > To: Loh, Tien Hock <tien.hock....@intel.com>; devel@edk2.groups.io; > ler...@redhat.com > Cc: leif.lindh...@linaro.org; ard.biesheu...@linaro.org > Subject: RE: [edk2-devel] Problem with decompression on EDK2 > > BaseTools VolInfo tool. Its input is the binary FvImage file. In the same > directory, GuidedSectionTools.txt (built in the FV directory) should be here. > > Thanks > Liming > > -----Original Message----- > > From: Loh, Tien Hock <tien.hock....@intel.com> > > Sent: Tuesday, October 1, 2019 10:34 AM > > To: Gao, Liming <liming....@intel.com>; devel@edk2.groups.io; > > ler...@redhat.com > > Cc: leif.lindh...@linaro.org; ard.biesheu...@linaro.org > > Subject: RE: [edk2-devel] Problem with decompression on EDK2 > > > > 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....@intel.com> > > > Sent: Sunday, September 29, 2019 3:06 PM > > > To: Loh, Tien Hock <tien.hock....@intel.com>; devel@edk2.groups.io; > > > ler...@redhat.com > > > Cc: leif.lindh...@linaro.org; ard.biesheu...@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....@intel.com>; devel@edk2.groups.io; > > > >ler...@redhat.com > > > >Cc: leif.lindh...@linaro.org; ard.biesheu...@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....@intel.com> > > > >> Sent: Friday, September 27, 2019 8:13 AM > > > >> To: devel@edk2.groups.io; ler...@redhat.com; Loh, Tien Hock > > > >> <tien.hock....@intel.com> > > > >> Cc: leif.lindh...@linaro.org; ard.biesheu...@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....@intel.com> > > > >> >Cc: leif.lindh...@linaro.org; ard.biesheu...@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 > > > >> > > > > >> > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#48587): https://edk2.groups.io/g/devel/message/48587 Mute This Topic: https://groups.io/mt/34296776/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
