Hello all, On Tue, Feb 19, 2019 at 8:28 PM Andre McCurdy <[email protected]> wrote: > On Tue, Feb 19, 2019 at 9:13 AM Leon Woestenberg <[email protected]> wrote: >> >> Hello Mike, >> >> sounds familiar. >> >> On Tue, 19 Feb 2019 at 17:55, Mike Looijmans <[email protected]> wrote: >>> >>> Took me a while to figure out why my board took 90 seconds to boot suddenly. >>> The issue turned out to be the ext4 partition created by wic. >> >> I suspect it's not WIC's fault. >>> >>> ZynqMP> load mmc 0:2 0x100000 /lib/firmware/fpga.bin >>> 19311092 bytes read in 85529 ms (219.7 KiB/s) >>> >>> Now if I boot the board rename and copy that file onto itself, then it's >>> suddenly normal again when I reboot the board: >>> >>> ZynqMP> load mmc 0:2 0x10000 >>> I'm not knowledgeable on ext4, so any ideas what's being passed onto the >>> image >>> creation tool that causes this? >> >> I suspect your version of U-Boot does not handle files spread across >> multiple filesystems (allocation) extends efficiently. >> >> Copying the file makes the copy being layed out in one extend probably. > > > If WIC is generating filesystem images from scratch there's no excuse for > files to be unnecessarily fragmented. > > Even if some of all of the boot time can be recovered by a patch to u-boot > that won't help systems which have already been deployed and don't have a way > to update the bootloader. > I am not sure if "fragmented" is the right term in terms of filesystem details. Filesystem allocation extents (not "extends" as I mistyped earlier) are different from heavy file fragmentation. However, I agree things can be made more optimal.
So, with adding the above, there are *two* issues at play here: 1) Most/older versions of U-Boot not able to efficiently load files from ext4 filesystems, that cross multiple extents. I am aware of two fixes, see below. 2) WIC uses mkext4fs in such a way that files can cross multiple (allocation) extents. This is sub-optimal and know to cause issues with many U-Boot versions (deployed on existing systems in the field). The problems shows "randomly" with large files being deployed to the ext4 filesystem. We (OE/Yocto) may want to fix this. >> I am aware of two fixes for U-Boot. I will look them up, and reply again to >> this thread. Google for these two commits. I cherry-picked the first one for my project and can confirm it brings back the desired performance. (Still assuming this is the identical cause as for TO/Mike.) commit 855b8e4f9f255415a7753819e392e4b5d984f35c Author: Matt Madison <[email protected]> Date: Sat Aug 19 08:46:46 2017 -0700 ext4: cache extent blocks during file reads A simpler and less-efficient approach to solving the problem with extent index blocks than what was in fc0fc50f38a4d7d0554558076a79dfe8b0d78cd5, but one that does not break write operations. Signed-off-by: Matt Madison <[email protected]> Regards, Leon. p.s. excuse the earlier HTML mail with signature -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
