ARM defconfig files
in [Kernel]
|
Prev: menuconfig: fix to center checklist correctly in a corner case
Next: [PATCH -next] classmate-laptop: fix for RFKILL=m, CMPC=y
From: Benjamin Herrenschmidt on 3 Jun 2010 21:10 On Thu, 2010-06-03 at 20:57 +0100, Russell King wrote: > config MACH_HALIBUT > bool "Halibut Board (QCT SURF7201A)" > select I2C if STD_CONFIG > select I2C_WHATEVER if STD_CONFIG > ... > > That means if you enable STD_CONFIG, you'll get everything that's required > selected. If you then disable STD_CONFIG, I believe Kconfig leaves > everything that was selected as still being selected. > > So, what you _could_ do is start off with a blank configuration, then > configure a kernel with STD_CONFIG enabled and you end up with everything > that's required. If you then want to disable something that's selected, > turn off STD_CONFIG first, and you'll be able to turn off individual > options. The main problem with that approach is that you can't choose what is to be modules and what is to be built-in. Yes, I do -hate- modules as much as you do. However, I have for example that little ARM based NAS box (DNS-323 from Belkin) and the firmware on that thing won't let me boot a kernel that is more than about 1.5M, tho I have about 6M of flash to put an initramfs with modules in it. Maybe we could extend select that way. IE. A way to say that a given option should be y or m by default, for example, while the user can still change it to be the other way around ? Cheers, Ben. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Tony Lindgren on 4 Jun 2010 01:00 * Kevin Hilman <khilman(a)deeprootsystems.com> [100604 03:17]: > Russell King <rmk(a)arm.linux.org.uk> writes: > > > On Thu, Jun 03, 2010 at 07:46:23PM +0300, Tony Lindgren wrote: > >> Compiling in multiple ARM platforms is trickier, we would have to get > >> rid of the duplicate defines like NR_IRQS, then have some common clock > >> framework etc. Then figure out some way to get rid of Makefile.boot. > >> Russell probably has some other things in mind that would have to be > >> changed to make this happen. > > > > - Find someway to handle the wide variety of interrupt controllers. > > - Be able to handle any multitude of V:P translations, including non-linear > > alongside linear transations. > > - Different PAGE_OFFSETs > > - Different kernel VM layouts allowing for a variety of different ioremap > > region sizes > > > > and so the list goes on... > > > > - Support for ARMv5, v6 and v7 in the same kernel image. > > On davinci, we've recently run into the problem where a new SoC in the > family is largely the same in terms of common HW blocks ands shared > peripherals with other davincis, but they upgraded from ARMv5 to > ARMv6. Attempting to build a single kernel that supports ARMv5 and > ARMv6 uncovered a pile of assumptions that v5 and v6 would never be in > the same kernel. Yeah we should sort that out, otherwise more things are slowly added that makes it harder to do. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Tony Lindgren on 4 Jun 2010 01:00 * Nicolas Pitre <nico(a)fluxnic.net> [100604 01:40]: > > Like I said, there is an effort to gradually overcome those issues one > by one. Unfortunately the same time we are slowly adding more and more ifdef else code that adds new blockers to compile in multiple ARM platforms into the same kernel. Some of the ones I've ran into over past few months are CONFIG_HAS_TLS_REG, CONFIG_VFPv3 and CONFIG_SMP. The first two are fixable though. Anyways, once we get the TLS and VFPv3 issues sorted out, we can do ARMv6 and ARMv7 booting binaries so I'll be able to whine about any new blockers getting added :) Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Felipe Balbi on 4 Jun 2010 01:30 On Fri, Jun 04, 2010 at 12:15:45AM +0200, ext Grant Likely wrote: >On Thu, Jun 3, 2010 at 3:17 PM, Tony Lindgren <tony(a)atomide.com> wrote: >> * Linus Torvalds <torvalds(a)linux-foundation.org> [100603 23:30]: >>> >>> and now you'd be able to basically generate a OMAP3EVM .config file by >>> just running "allnoconfig" on that Kconfig.omap3_evm file. But it would >>> only have to select the parts that are specific for the EVM platform, >>> because the generic OMAP3 support would be picked by the Kconfig.omap3 >>> file, which in turn would not have to worry about the generic ARM parts >>> etc. >>> >>> See? >> >> Sounds like a good improvment to me. > >(as one who just finishing updating powerpc defconfigs...) ditto here. > I'd be happy to be rid of all the existing ppc defconfigs. > >I like the Kconfig approach, but to be useful (at least for me) there >would need to be a way to get Kconfig to complain about things like >broken selects as in your example. Still selects needs to be improved so we have a 'select_module' option that would make that driver a module instead of built-in. -- balbi DefectiveByDesign.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Tony Lindgren on 4 Jun 2010 01:40
* Benjamin Herrenschmidt <benh(a)kernel.crashing.org> [100604 03:56]: > On Thu, 2010-06-03 at 19:13 +0100, Russell King wrote: > > On Thu, Jun 03, 2010 at 07:46:23PM +0300, Tony Lindgren wrote: > > > Compiling in multiple ARM platforms is trickier, we would have to get > > > rid of the duplicate defines like NR_IRQS, then have some common clock > > > framework etc. Then figure out some way to get rid of Makefile.boot. > > > Russell probably has some other things in mind that would have to be > > > changed to make this happen. > > Ok so multiple platforms in one kernel is a different subject and could > warrant a different thread. However it's interesting because we do that > quite well on powerpc :-) > > (Note also that while the device-tree helps make it even easier, it's > not fundamentally necessary to achieve that goal). Yeah both platform data and device tree should work just fine. > > - Find someway to handle the wide variety of interrupt controllers. > > We have a very nice and simple interrupt mapping scheme on powerpc that > makes that quite trivial along with the generic irq changes that went in > a couple of years ago (which we mostly based on ARM iirc). > > We have a structure that define an interrupt numbering domain (which can > be associated 1:1 with a given controller but doesn't have to), and > simple APIs to allocate "linux" interrupt numbers associated with a > given domain/HW number pair. From there, we support multiple domains, > arbitrary layout and cascades, etc... > > > - Be able to handle any multitude of V:P translations, including non-linear > > alongside linear transations. > > For the kernel "linear" mapping you mean ? Yeah, that's a bit of a sore > spot, though sparsemem + vmemmap helps a lot. Creative use of dynamic > patching would do nicely here though it's problematic with XIP kernels > (though my understanding is that those are getting less common). > > > - Different PAGE_OFFSETs > > Does this have to be a per SoC or mach family ? Users can change > PAGE_OFFSET on powerpc to change the user/kernel split (for example in > order to get more ioremap space or avoid turning on HIGHMEM) but it's in > the domain of the config and a kernel with a lower PAGE_OFFSET can > always boot all platforms even those that don't require it. > > Alternatively, you can always try to do like we do on ppc64 with fully > runtime relocatable kernels :-) > > > - Different kernel VM layouts allowing for a variety of different ioremap > > region sizes > > > > and so the list goes on... > > That's quite easily done at runtime. Thanks for all the good info, that will be handy when trying to figure out how to change things to support multiple ARM platforms. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |