On Tue 12 Mar 2024 at 17:06, Mark Brown <broonie@xxxxxxxxxx> wrote: > [[PGP Signed Part:Undecided]] > On Tue, Mar 12, 2024 at 05:29:25PM +0100, Jerome Brunet wrote: > >> Mark, I suspect the boards you have (like the libretech Alta/Solitude or >> the kvim3 maybe) will show the same thing. > > I don't have the kvim3 but I can try with the other two (modulo pain > with u-boot), it'll be tomorrow now though. I've check the other boards from same SoC family (g12 and sm1) for the same kernel build: https://linux.kernelci.org/test/job/mainline/branch/master/kernel/v6.8-rc7-250-g137e0ec05aeb/plan/baseline/ * Only the u200 is failing. The others devices of the same family are fine. * The u200 is the only one being test with gcc-10 / defconfig + debug * The others have been tested with clang-16 / defconfig + CONFIG_ARM64_64K_PAGES I've checked locally with gcc-13 on the vim3l (sm1 - s905x3) * OK with defconfig * Problem reproduced with defconfig + debug fragment from kCI - Observations: * Kernel is extremely fat (150+ MB) * Boot process incredibly slow. Fragment is here: https://storage.kernelci.org/mainline/master/v6.8-rc7-250-g137e0ec05aeb/arm64/defconfig+debug/gcc-10/config/kernelci.config I'll continue to check but this is apparently related to the options turned on by the debug fragment. Maybe it could be interesting to check another non-intel SoC manufacturer using DPCM with this fragment ? (another device relying on cleared ch_maps - Renesas and/or MTK maybe ?) -- Jerome
