Message-Id: <201301021448.20119.arnd@arndb.de>
Date:	Wed, 2 Jan 2013 14:48:19 +0000
From:	Arnd Bergmann <arnd@...db.de>
To:	Vineet Gupta <Vineet.Gupta1@...opsys.com>
Cc:	Gilad Ben Yossef <giladb@...hip.com>,
	Noam Camus <noamc@...hip.com>, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH v1 26/31] ARC: Build system: Makefiles, Kconfig, Linker script

On Wednesday 02 January 2013, Vineet Gupta wrote:
> On Wednesday 07 November 2012 07:43 PM, Arnd Bergmann wrote:
> > On Wednesday 07 November 2012, Vineet Gupta wrote:
> > 
> > Platform selection should generally be non-exclusive. Just remove the
> > "choice" statement here, and make sure that any platforms can be enabled
> > together to build a single kernel.
> 
> So technically this is not in same league as usage of devicetree. Although it
> seems to have it's own merits (single image, code coverage,..) but is this a hard
> requirement for all arches. Here's my problem.
> 
> We have default implementations of clocksource using in-core local TIMER1. This
> however might not suffice for some SMP ARC SoCs which need cross-core synchronized
> timers. Obviously they want to use their own versions. In orig code (not v1 - but
> in my new v2) I have a platform specific hook local_counter_setup() called from
> time_init(). With #def PLAT1 and #def PLAT2, there could be 2 mutually exclusive
> versions of those. With the "all-platform-build-together" paradigm, this simple
> design is not possible - not to mention the needless code bloat for a simple run
> in simulator. So now using devicetree, I first need to find what platform we are
> on and then need to setup a platform specific function pointer (and same applies
> to several other platform specific stuff). Is there a better way of doing this -
> maybe the long dy has taken toll on me :-(

Regarding the code bloat, there should be practically no run-time cost, because
all the decisions are made in __init functions that are discarded after boot.
There will be a little vmlinux size overhead from turning build-time into
run-time configuration though. Of course you don't have to always build
everything together, it's totally fine to have a separate defconfig file
for each platform that just enables the parts that are required, as long
as it's also possible to build an allyesconfig that enables everything
(or most things, in cases where there are hard reasons not to make something
a run-time decision)

The generic timer code is already quite flexible and allows plugging in
clocksources at run-time, as this is essential to do on x86.

The way to do this with device tree is normally not to identify a global
"platform", but rather to identify the individual devices. E.g. when
you have an SMP system with a synchronized timer, there would be
a device node describing that timer and your driver looks for that node.

> >> +menu "ARC CPU Configuration"
> >> +
> >> +choice
> >> +	prompt "ARC Core"
> >> +	default ARC_CPU_770
> >> +
> >> +config ARC_CPU_750D
> >> +	bool "ARC750D"
> >> +	help
> >> +	  Support for ARC750 core
> >> +
> >> +config ARC_CPU_770
> >> +	bool "ARC770"
> >> +	select ARC_CPU_REL_4_10
> >> +	help
> >> +	  Support for ARC770 core introduced with Rel 4.10 (Summer 2011)
> >> +	  This core has a bunch of cool new features:
> >> +	  -MMU-v3: Variable Page Sz (4k, 8k, 16k), bigger J-TLB (128x4)
> >> +                   Shared Address Spaces (for sharing TLB entires in MMU)
> >> +	  -Caches: New Prog Model, Region Flush
> >> +	  -Insns: endian swap, load-locked/store-conditional, time-stamp-ctr
> >> +
> >> +endchoice
> > 
> > Same thing here: If the different CPUs can in theory run the same kernel
> > code, they should allow that. It doesn't stop you from making the default
> > to enable only one of them and optimize for that case.
> 
> Background: ARC770 supports newer instructions (LOCK/SCOND) + MMUv3 which are not
> available on ARC750. So code needs to be built differently for each. Having said
> that above config items don't have any code under them - they are just high level
> selectors for correct MMU versions and e.g. whether we allow the usage of new insns.

So a kernel built for ARC750 could potentially run on an ARC770, but not use
all the features, right?

The way we handle this on ARM and PowerPC is to allow selecting each CPU
individually, but falling back on the common subset. So you could build
a kernel that supports running on ARC750 and on ARC770, but that would 
make it impossible to use SMP, so on an ARC770 SMP machine, it would
only run on the first CPU.

If ARC770 cannot actually run the MMU_V2 code, that would mean that they
are indeed mutually exclusive by design, unless you also support a NOMMU
kernel. In that case you could only build a kernel for both 750 and 770
if you don't use the MMU. That would be much less interesting for actually
running things, but it could still make sense for build testing.

If you don't need NOMMU support otherwise (I forgot whether or not you
have this), you should of course not implement it just for this.

> > 
> > For MMU, page size and endianess, I would not expect that to work though,
> > so they probably need to remain mutually exclusive.
> 
> Ofcourse - given that PAGE_SIZE needs to be a compile time constant.

Actually, it is possible to support multiple page sizes (I think IA64
does this), but I don't recommend implementing it unless you have
a specific need for that.

	Arnd

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists