From: Vineet Gupta <Vineet.Gupta1@synopsys.com> To: Arnd Bergmann <arnd@arndb.de> Cc: "linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>, "Gilad Ben Yossef" <giladb@ezchip.com>, Noam Camus <noamc@ezchip.com>, <linux-kernel@vger.kernel.org> Subject: Re: [RFC PATCH v1 26/31] ARC: Build system: Makefiles, Kconfig, Linker script Date: Thu, 3 Jan 2013 13:28:13 +0530 [thread overview] Message-ID: <50E53A15.8040007@synopsys.com> (raw) In-Reply-To: <201301021448.20119.arnd@arndb.de> 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
WARNING: multiple messages have this Message-ID (diff)
From: Vineet Gupta <Vineet.Gupta1@synopsys.com> To: Arnd Bergmann <arnd@arndb.de> Cc: "linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>, Gilad Ben Yossef <giladb@ezchip.com>, Noam Camus <noamc@ezchip.com>, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH v1 26/31] ARC: Build system: Makefiles, Kconfig, Linker script Date: Thu, 3 Jan 2013 13:28:13 +0530 [thread overview] Message-ID: <50E53A15.8040007@synopsys.com> (raw) In-Reply-To: <201301021448.20119.arnd@arndb.de> 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
next prev parent reply other threads:[~2013-01-03 7:58 UTC|newest] Thread overview: 141+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-11-07 9:47 [RFC Patch v1 00/31] Synopsys ARC Linux kernel Port Vineet Gupta 2012-11-07 9:47 ` [RFC PATCH v1 01/31] ARC: Generic Headers Vineet Gupta 2012-11-07 9:47 ` [RFC PATCH v1 02/31] ARC: irqflags Vineet Gupta 2012-11-12 19:50 ` Thomas Gleixner 2013-01-01 7:44 ` Vineet Gupta 2013-01-01 7:44 ` Vineet Gupta 2012-11-07 9:47 ` [RFC PATCH v1 03/31] ARC: atomic/bitops/cmpxchg/barriers Vineet Gupta 2012-11-07 9:47 ` [RFC PATCH v1 04/31] asm-generic headers: uaccess.h to conditionally define segment_eq() Vineet Gupta 2012-11-07 9:47 ` [RFC PATCH v1 05/31] ARC: uaccess friends Vineet Gupta 2012-11-07 9:47 ` [RFC PATCH v1 06/31] asm-generic headers: Allow yet more arch overrides in checksum.h Vineet Gupta 2012-11-07 9:47 ` [RFC PATCH v1 07/31] ARC: checksum/byteorder/swab routines Vineet Gupta 2012-11-07 9:47 ` [RFC PATCH v1 08/31] ARC: Fundamental ARCH data-types/defines Vineet Gupta 2012-11-08 7:10 ` Jonas Bonn 2012-11-08 18:52 ` Vineet Gupta 2012-11-08 20:36 ` Jonas Bonn 2012-11-12 13:58 ` Vineet Gupta 2012-11-12 14:12 ` Arnd Bergmann 2012-11-07 9:47 ` [RFC PATCH v1 09/31] ARC: spinlock/rwlock/mutex primitives Vineet Gupta 2012-11-07 9:47 ` [RFC PATCH v1 10/31] ARC: string library Vineet Gupta 2012-11-07 9:47 ` [RFC PATCH v1 11/31] ARC: Low level IRQ/Trap/Exception(non-MMU) Handling Vineet Gupta 2012-11-16 4:58 ` Al Viro 2012-12-27 9:00 ` Vineet Gupta 2012-12-27 9:00 ` Vineet Gupta 2012-12-27 13:29 ` Vineet Gupta 2012-12-27 13:29 ` Vineet Gupta 2012-11-07 9:47 ` [RFC PATCH v1 12/31] ARC: Interrupt Handling Vineet Gupta 2012-11-12 20:08 ` Thomas Gleixner 2013-01-01 10:46 ` Vineet Gupta 2013-01-01 10:46 ` Vineet Gupta 2012-11-07 9:47 ` [RFC PATCH v1 13/31] ARC: Non-MMU Exception Handling Vineet Gupta 2012-11-07 9:47 ` [RFC PATCH v1 14/31] ARC: syscall support Vineet Gupta 2012-11-07 14:21 ` Arnd Bergmann 2012-11-09 9:50 ` James Hogan 2012-11-09 9:50 ` James Hogan 2012-11-13 11:41 ` James Hogan 2012-11-13 11:41 ` James Hogan 2012-11-13 12:01 ` Jonas Bonn 2012-11-13 12:11 ` James Hogan 2012-11-13 12:11 ` James Hogan 2012-11-14 12:23 ` Arnd Bergmann 2012-11-14 12:31 ` James Hogan 2012-11-14 12:31 ` James Hogan 2012-11-13 10:13 ` Gilad Ben-Yossef 2012-11-13 10:37 ` Arnd Bergmann 2012-11-15 6:15 ` Vineet Gupta 2012-11-15 6:15 ` Vineet Gupta 2012-11-15 12:35 ` Arnd Bergmann 2013-01-17 5:13 ` Vineet Gupta 2013-01-17 5:13 ` Vineet Gupta 2012-11-07 9:47 ` [RFC PATCH v1 15/31] ARC: Process/scheduling/clock/Timers/Delay Management Vineet Gupta 2012-11-12 20:29 ` Thomas Gleixner 2013-01-02 7:13 ` Vineet Gupta 2013-01-02 7:13 ` Vineet Gupta 2013-01-02 8:45 ` Vineet Gupta 2013-01-02 8:45 ` Vineet Gupta 2013-01-04 13:01 ` Frederic Weisbecker 2012-11-07 9:47 ` [RFC PATCH v1 16/31] ARC: Signal handling Vineet Gupta 2012-11-16 5:26 ` Al Viro 2012-12-28 12:34 ` Vineet Gupta 2012-12-28 12:34 ` Vineet Gupta 2012-12-28 12:42 ` [PATCH 1/2] ARC: [Review] Preparing to fix incorrect syscall restarts due to signals Vineet Gupta 2012-12-28 12:42 ` Vineet Gupta 2012-12-28 12:42 ` [PATCH 2/2] ARC: [Review] Prevent incorrect syscall restarts Vineet Gupta 2012-12-28 12:42 ` Vineet Gupta 2012-11-07 9:47 ` [RFC PATCH v1 17/31] ARC: Cache Flush Management Vineet Gupta 2012-11-07 9:47 ` [RFC PATCH v1 18/31] ARC: Page Table Management Vineet Gupta 2012-11-07 9:47 ` [RFC PATCH v1 19/31] ARC: MMU Context Management Vineet Gupta 2012-11-07 9:47 ` [RFC PATCH v1 20/31] ARC: MMU Exception Handling Vineet Gupta 2012-11-07 9:47 ` [RFC PATCH v1 21/31] ARC: TLB flush Handling Vineet Gupta 2012-11-07 9:47 ` [RFC PATCH v1 22/31] ARC: Page Fault handling (incl uaccess fixup) Vineet Gupta 2012-11-07 9:47 ` [RFC PATCH v1 23/31] ARC: I/O and DMA Mappings Vineet Gupta 2012-11-07 9:47 ` [RFC PATCH v1 24/31] ARC: startup #1: low-level, setup_arch(), /proc/cpuinfo, mem init Vineet Gupta 2012-11-07 9:47 ` [RFC PATCH v1 25/31] ARC: [plat-arcfpga] Hooking up platform to ARC UART Vineet Gupta 2012-11-07 14:16 ` Arnd Bergmann 2013-01-07 13:10 ` Vineet Gupta 2013-01-07 13:10 ` Vineet Gupta 2013-01-07 13:46 ` Arnd Bergmann 2013-01-07 14:04 ` Vineet Gupta 2013-01-07 14:04 ` Vineet Gupta 2013-01-07 14:36 ` Arnd Bergmann 2013-01-14 7:35 ` early init dt for earlyprintk (was Re: [RFC PATCH v1 25/31] ARC: [plat-arcfpga] Hooking up platform to ARC UART) Vineet Gupta 2013-01-14 7:35 ` Vineet Gupta 2013-01-14 9:48 ` James Hogan 2013-01-14 9:48 ` James Hogan 2013-01-14 10:09 ` Vineet Gupta 2013-01-14 10:09 ` Vineet Gupta 2013-01-14 10:54 ` Arnd Bergmann 2013-01-17 7:29 ` [RFC PATCH v1 25/31] ARC: [plat-arcfpga] Hooking up platform to ARC UART Vineet Gupta 2013-01-17 7:29 ` Vineet Gupta 2013-01-17 10:52 ` Arnd Bergmann 2012-11-07 9:47 ` [RFC PATCH v1 26/31] ARC: Build system: Makefiles, Kconfig, Linker script Vineet Gupta 2012-11-07 14:13 ` Arnd Bergmann 2013-01-02 14:30 ` Vineet Gupta 2013-01-02 14:48 ` Arnd Bergmann 2013-01-03 7:58 ` Vineet Gupta [this message] 2013-01-03 7:58 ` Vineet Gupta 2013-01-03 8:25 ` Arnd Bergmann 2013-03-11 12:29 ` SYSV IPC broken for no-legacy syscall kernels (was Re: [RFC PATCH v1 26/31] ARC: Build system: Makefiles, Kconfig, Linker script) Vineet Gupta 2013-03-11 12:29 ` Vineet Gupta 2013-03-11 12:44 ` James Hogan 2013-03-11 12:44 ` James Hogan 2013-03-11 12:56 ` Vineet Gupta 2013-03-11 12:56 ` Vineet Gupta 2013-03-11 13:07 ` James Hogan 2013-03-11 13:07 ` James Hogan 2013-03-11 13:30 ` Arnd Bergmann 2013-03-11 13:48 ` Vineet Gupta 2013-03-11 13:48 ` Vineet Gupta 2013-03-11 14:50 ` Arnd Bergmann 2012-11-15 17:49 ` [RFC PATCH v1 26/31] ARC: Build system: Makefiles, Kconfig, Linker script James Hogan 2012-11-15 17:49 ` James Hogan 2012-11-15 19:30 ` Ralf Baechle 2012-11-16 6:36 ` Vineet Gupta 2012-11-16 6:36 ` Vineet Gupta 2012-11-07 9:47 ` [RFC PATCH v1 27/31] ARC: Last bits (stubs) to get to a running kernel with UART Vineet Gupta 2012-11-07 9:47 ` [RFC PATCH v1 28/31] ARC: split ret_from_fork, simplify kernel_thread() Vineet Gupta 2012-11-07 9:47 ` [RFC PATCH v1 29/31] ARC: switch to generic kernel_thread() Vineet Gupta 2012-11-07 9:47 ` [RFC PATCH v1 30/31] ARC: switch to generic kernel_execve() and sys_execve() Vineet Gupta 2012-11-16 4:08 ` Al Viro 2012-11-17 14:01 ` Vineet Gupta 2012-11-17 14:01 ` Vineet Gupta 2012-11-07 9:47 ` [RFC PATCH v1 31/31] ARC: [plat-arcfpga] defconfig Vineet Gupta 2012-11-07 14:06 ` Arnd Bergmann 2012-11-12 14:18 ` James Hogan 2012-11-12 14:18 ` James Hogan 2012-11-12 14:21 ` Arnd Bergmann 2012-11-07 14:36 ` [RFC Patch v1 00/31] Synopsys ARC Linux kernel Port Arnd Bergmann 2012-11-08 19:09 ` Vineet Gupta 2012-11-07 20:46 ` Gilad Ben-Yossef 2012-11-20 13:47 ` Pavel Machek 2012-11-20 13:49 ` Vineet Gupta 2012-11-20 13:49 ` Vineet Gupta 2012-11-20 13:59 ` Pavel Machek 2012-11-20 14:17 ` Vineet Gupta 2012-11-20 14:17 ` Vineet Gupta 2013-01-18 19:46 ` Pavel Machek 2013-01-18 22:17 ` Arnd Bergmann 2013-01-19 10:15 ` Pavel Machek 2013-01-19 12:32 ` Vineet Gupta 2013-01-19 12:32 ` Vineet Gupta 2013-01-19 17:02 ` Pavel Machek
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=50E53A15.8040007@synopsys.com \ --to=vineet.gupta1@synopsys.com \ --cc=arnd@arndb.de \ --cc=giladb@ezchip.com \ --cc=linux-arch@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=noamc@ezchip.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.