On Wednesday 02 January 2013 08:18 PM, Arnd Bergmann wrote:
> 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:
>>> +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?
Only for features which are non conflicting - so even now a CONFIG_ARC_CPU_750
built kernel (so no LLOCK/SCOND support) will run fine on 770 hardware (which has
LLOCK/SCOND)- assuming everything else being constant. However MMUv3 (770 only)
has a different programming model vs. MMUv2 (e.g. TLB descriptor layout among
others) hence a kernel for MMU v2 "simply" can't run on MMUv3 w/o making
runtime-checks or runtime-overrides (akin to function pointers) in things like TLB
refill handlers and such.
> 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.
Good for pre-built distros and such ! Nice concept - I like it.
> If ARC770 cannot actually run the MMU_V2 code, that would mean that they
> are indeed mutually exclusive by design,
Given the immense hardware configurability of ARC, all crazy combinations are
possible - how many are practically used is a different topic. So someone could in
theory build 770 with MMUv2 and infact the current build system even allows that.
See ARC_CPU_{750,770} are only about selecting a bunch of defaults (MMU ver,
LLOCK) - to prevent the user from hand doing that. So lets say we rip off both of
these (to emulate kernel built for one running on other) - then it would boil down
to letting support for both v2 and v3 co-exist (not to forget there's also an
arcane historic v1). Now these fellows really are mutually exclusive by design:
* code written for v3 won't work on v2 (e.g. ARC_REG_IC_PTAG doesn't exist)
* code written for v2 won't work on v3 (e.g ARC_REG_IC_PTAG needs to be written
for correct behaviour)
> 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.
NOMMU is not supported yet.
So how do we conclude on this topic - given the caveats above ?
Thx,
-Vineet
--
To unsubscribe from this list: send the line "unsubscribe linux-arch" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
