On 1 August 2013 16:30, Ryan Harkin <ryan.har...@linaro.org> wrote: > On 1 August 2013 07:57, Andy Green <andy.gr...@linaro.org> wrote: >> On 1 August 2013 14:11, Viresh Kumar <viresh.ku...@linaro.org> wrote: >>> Hi Andrey, >>> >>> linaro/configs/* is getting bigger and bigger, probably its the right time >>> to >>> organize it better for the future. There can be multiple things that we can >>> do to avoid confusions of names but for now probably we can create >>> separate directories for boards, rootfs & kernel fragments? Or some >>> other idea that you might have? >> >> Just a thought these seem to me like they are covering up for missing >> "select xxx" in the related Kconfig option (eg, CONFIG_ANDROID), or >> stuff that should be in the defconfig (eg, omap4, vexpress). > > Is the platform specific defconfig still relevant in a multiarch > kernel? I guess the fragments should adding items missing from the > default multiarch config. Excuse my ignorance, 'cause I don't know > how multiarch works...
It lets you have more than one CONFIG_ARCH_blah at once enabled in the config and working in the one kernel binary . You give it one of the valid dtbs to tell it what it is at runtime. We use it to have the CONFIG_ARCH_(dual aa9 SoC) and CONFIG_ARCH_(big.LITTLE SoC) in the same kernel binary so the same kernel can start up on both platforms. Once it's started though, it's just bloat to have peripheral drivers present on only one of the platforms built-in to the monolithic kernel. For example those two SoCs have different video IPs, so we need them to be both built as modules and then use the different Device Tree definition to bind to just the right module at runtime so it all works out nicely. So you do still need to tell the kernel what drivers are relevant to your combined set of arches, your defconfig needs to reflect that (and builds everything selected as modules where possible). > Historically, the main reason for us creating the frags was because of > the platforms (eg, Ubuntu) adding lots of config options that weren't > in the defconfig. The vexpress defconfig has always been broken. But > over-riding the defconfig with Ubuntu/Android/whatever options was a > bigger bodge than creating fragments. Right I think eg, adding selects to CONFIG_ANDROID in its Kconfig, or adding CONFIG_ANDROID_TYPICAL to do that and select CONFIG_ANDROID would soak up some of them anyway. General Ubuntuesque options I don't know, maybe that's more legit. > So I think they are still important for Linaro's builds. Escpecially > as we aren't building multiarch kernels for all our platforms yet. > >> >> There's also an issue the fragments are all =y when for >> ARCH_MULTIPLATFORM, it implies all things not needed for rootfs mount >> need to be =m. > > That's a good point and something we should look into. We should > really be using multiarch kernels sooner rather than later, right? I think it makes a lot of sense for each vendor to have their own stuff building as a single multiarch kernel if possible. Then you can just provide one image with one or two kernels (LPAE and non-LPAE don't play together) plus a lot of modules and dtbs that covers all the cases. It will be possible to enable different vendor arches all at the same time as well, but the different bootloader requirements situation will scuttle that. Some combinations will work like Fujitsu AA9 has bootloader in internal NOR, it can share an SD with OMAP4 using MLO inside VFAT okay. At any rate to get the SoC support upstream now you have to meet the checklist for ARCH_MULTIPLATFORM so it's certainly the way of the future. -Andy >> >> -Andy >> >>> -- >>> viresh >>> >>> _______________________________________________ >>> linaro-dev mailing list >>> linaro-dev@lists.linaro.org >>> http://lists.linaro.org/mailman/listinfo/linaro-dev >> >> _______________________________________________ >> linaro-dev mailing list >> linaro-dev@lists.linaro.org >> http://lists.linaro.org/mailman/listinfo/linaro-dev _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
