Messages in this thread | | | Date | Tue, 20 Sep 2022 15:46:13 +0100 | From | Paul Cercueil <> | Subject | Re: Usefulness of CONFIG_MACH_JZ47* |
| |
Le mar., sept. 20 2022 at 16:19:41 +0200, H. Nikolaus Schaller <hns@goldelico.com> a écrit : > Hi Paul, > >> Am 20.09.2022 um 15:33 schrieb Paul Cercueil <paul@crapouillou.net>: >> >> >> >> Le mar., sept. 20 2022 at 14:31:38 +0200, H. Nikolaus Schaller >> <hns@goldelico.com> a écrit : >>> Hi Paul, >>>> Am 20.09.2022 um 11:09 schrieb Paul Cercueil >>>> <paul@crapouillou.net>: >>>> Hi Nikolaus, >>>> Le mar., sept. 20 2022 at 08:31:30 +0200, H. Nikolaus Schaller >>>> <hns@goldelico.com> a écrit : >>>>> Hi Paul, >>>>> it seems as if there aren't many places left over where the >>>>> MACH_JZ47* configs are still in use: >>>>> drivers/char/hw_ramdom/Kconfig >>>>> drivers/clk/ingenic/Kconfig >>>>> drivers/gpu/drm/ingenic/Kconfig >>>>> drivers/pinctrl/pinctrl-ingenic.c >>>>> Is it possible to get rid of them and just have >>>>> CONFIG_MACH_INGENIC_GENERIC? >>>>> This might simplify my defconfig for multiple machines. >>>> CONFIG_MIPS_GENERIC_KERNEL=y >>> This breaks compilation for me, e.g. >>> arch/mips/mm/cache.c:203:6: error: 'cpu_has_tx39_cache' undeclared >>> (first use in this function) >> >> v6.0-rc does not have 'cpu_has_tx39_cache' anywhere in that file, >> or in arch/mips/ for that matter. It was removed in v5.18. >> >> And a v5.17 kernel compiles fine here with these options enabled. >> So it's a problem on your side, I guess. > > Ah, you were right. > > I have a patch included which was provided by > zhouyanjie@wanyeetech.com > ("MIPS: mm: Add Ingenic XBurst SoCs specific cache driver."). > > It is intended to improve caching and is part of jz4780 SMP support > which we wanted to have. > AFAIR it was either not posted to lkml or rejected or superseded. > >> >>>> CONFIG_BOARD_INGENIC=y >>> This config option does not exist (at least in v6.0-rc). Probably >>> you refer to CONFIG_INGENIC_GENERIC_BOARD. >> >> No, I do not, and yes, it exists. > > Ah, I grepped for CONFIG_BOARD_INGENIC but it exists only in one > Kconfig as BOARD_INGENIC. > But what is then the difference to CONFIG_INGENIC_GENERIC_BOARD and > CONFIG_MACH_INGENIC_GENERIC?
CONFIG_BOARD_INGENIC=y means you are building a generic MIPS kernel that happens to support Ingenic boards. In this case, the kernel has a lot of features enabled that might not be useful on specific Ingenic boards, because the kernel needs to support other SoCs. This option selects CONFIG_MACH_INGENIC_GENERIC=y, which in turn selects MACH_INGENIC=y and every MACH_JZ* and MACH_X* there is.
If you instead set MACH_INGENIC_SOC=y as your "Machine Selection -> System Type", this means your kernel will run specifically on Ingenic SoCs and isn't expected to work anywhere else. By default the "Machine Type" will be CONFIG_INGENIC_GENERIC_BOARD=y aka. "Generic board", which can be used to support any board with an Ingenic SoC. This option also selects CONFIG_MACH_INGENIC_GENERIC=y. If you choose a different "machine type", for instance JZ4780_CI20=y, then only MACH_JZ4780=y will be selected, and all the code unrelated to the JZ4780 SoC will be disabled.
Cheers, -Paul
> >> >>> As far as I see, this does not choose to build any device tree >>> blob. >>> I tried some patch to get the .dtb built, but the resulting kernel >>> does not show any activity. >>> If I e.g. switch back from CONFIG_INGENIC_GENERIC_BOARD=y to >>> CONFIG_JZ4780_CI20=y the kernel works. >> >> Because in the first case you build a generic kernel, which does >> not embed any .dtb, and you are responsible for providing the kernel >> with the blob at boot time; while if you build with >> CONFIG_JZ4780_CI20=y it embeds the .dtb inside the kernel. >> >> You can embed the .dtb into the generic kernel at compile-time too, >> have a look at "Kernel type -> Kernel appended dtb support." Not >> sure why you'd want that for a generic kernel, though. > > Ah, I remember. Since I usually code 99% of my time for ARM systems > with separate .dtb files chosen by the boot loader, I forgot that we > have to append the .dtb on the CI20 and Alpha400. So there is no good > solution for a "universal" kernel binary either. > >> >>>> Then you can support all Ingenic-based boards alongside other >>>> MIPS boards. >>> Yes, I know, but why are the MACH_JZ47* not replaced by >>> CONFIG_MACH_INGENIC_GENERIC if they are almost unused or completely >>> removed? >> >> They *are* used. > > Well, only in a handful of places as it looks like. > >> >>> BTW: there are also seems to be some board specific CONFIGs in >>> processor specific code (e.g. CONFIG_JZ4780_CI20 in irqchip code). >> >> rgrep CI20 drivers/irqchip/ >> >> returns nothing for me. > > Ah, again an inofficial patch which is part of the SMP stuff > ("irqchip: Ingenic: Add percpu IRQ support for X2000."). > >> >>> So selecting a MACH is not sufficient to get these features. >>> All this looks a little fragile and incomplete... Maybe if I find >>> some time (which is unfortunately quite unlikely) I can propose >>> some fixes. >> >> It is not "fragile and incomplete", it works as intended, and it's >> a feature I use often. > > Yes, seems as if you are right. We may have added too many useful > patches which did not go upstreamand get in conflict with upstream > features. > > BR and thanks for helping to better understand, > Nikolaus > >> >> -Paul >> >
| |