On 2/11/23 12:06, Arnd Bergmann wrote:
On Sat, Feb 11, 2023, at 19:24, Guenter Roeck wrote:
On Thu, Sep 29, 2022 at 03:38:56PM +0200, Arnd Bergmann wrote:
All board support that was marked as 'unused' earlier can
now be removed, leaving the five machines that that still
had someone using them in 2022, or that are supported in
qemu.
Cc: Aaro Koskinen <aaro.koskinen@xxxxxx>
Cc: Janusz Krzysztofik <jmkrzyszt@xxxxxxxxx>
Cc: Tony Lindgren <tony@xxxxxxxxxxx>
Cc: linux-omap@xxxxxxxxxxxxxxx
Signed-off-by: Arnd Bergmann <arnd@xxxxxxxx>
After this patch I can no longer boot the qemu sx1 emulation from mmc.
Is this on purpose ?
Thanks a lot for the report and for tracking it down to this commit!
This is not intentional and I don't see what is going on exactly.
I had another look at the patch but don't see anything wrong with
it, as it should only removed files that are dead code after the
unused boards started depending on CONFIG_EXPERT.
I never managed to get sx1 to boot in qemu in the first place, so
unfortunately I can't reproduce this here. Are you able to
narrow it down a little further? My first guess was that
something inadvertently changed in the output of 'make defconfig',
but the only symbols I see there are CONFIG_ARCH_OMAP730 and
CONFIG_ARCH_OMAP850, and I don't see any effect that they would
have on an OMAP310/1510.
What happens if you disable those options manually on a working kernel?
Those are not even listed as possible options. The key difference
in defconfig is:
44a45
> CONFIG_IOSCHED_BFQ=y
79a81
> CONFIG_MMC_OMAP=y
and the latter is now disabled because
depends on TPS65010 || !MACH_OMAP_H2
was changed to
depends on TPS65010
and TPS65010 is not enabled in my configuration.
Removing the dependency of MMC_OMAP on TPS65010 fixes the problem.
Guenter
