On Fri, Jul 06, 2012 at 10:05:41PM +0100, Catalin Marinas wrote:
> This set of patches implements the core Linux support for the AArch64
> (64-bit ARM) architecture.
...
> These patches are also available on this branch:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64.git
On Sat, 2012-07-07 at 19:27:12 +, Arnd Bergmann wrote:
> On Saturday 07 July 2012, Olof Johansson wrote:
> > > ARM introduced AArch64 as part of the ARMv8 architecture
> >
> > With the risk of bikeshedding here, but I find the name awkward. How
> > about just naming the arch port arm64 instead
On Wed, Jul 18, 2012 at 12:35 PM, Jon Masters wrote:
>
> So we should think with a
> mindset of 2-3 years from now rather than where we were yesterday.
Why do you think aarch64 would be a better name 2-3 years from now?
And why do you think ARM management magically has good taste? They got
the P
On 07/18/2012 01:14 PM, Catalin Marinas wrote:
> Debian has different names for the architecture and compiler triplet:
> amd64 with x86_64-linux-gnu, similar for x32. None of these match the
> arch/x86/ Linux directory. Even if there is some confusion initially, it
> will go away in a relatively s
Catalin Marinas writes:
> On Wed, Jul 18, 2012 at 04:27:12PM +0100, Dennis Gilmore wrote:
>> El Tue, 17 Jul 2012 22:33:33 -0400
>> Jon Masters escribió:
>> > On 07/17/2012 06:35 PM, Joe Perches wrote:
>> > > On Tue, 2012-07-17 at 23:18 +0100, Catalin Marinas wrote:
>> > >
>> > >> The uname will
On Wed, Jul 18, 2012 at 04:27:12PM +0100, Dennis Gilmore wrote:
> El Tue, 17 Jul 2012 22:33:33 -0400
> Jon Masters escribió:
> > On 07/17/2012 06:35 PM, Joe Perches wrote:
> > > On Tue, 2012-07-17 at 23:18 +0100, Catalin Marinas wrote:
> > >
> > >> The uname will still report
> > >> "aarch64" to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
El Tue, 17 Jul 2012 22:33:33 -0400
Jon Masters escribió:
> On 07/17/2012 06:35 PM, Joe Perches wrote:
> > On Tue, 2012-07-17 at 23:18 +0100, Catalin Marinas wrote:
> >
> >> The uname will still report
> >> "aarch64" to match the compiler triplet and
Hi Jon,
On Wed, Jul 18, 2012 at 06:35:40AM +0100, Jon Masters wrote:
> On 07/06/2012 05:05 PM, Catalin Marinas wrote:
>
> > These patches are also available on this branch:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64.git
> > upstream
>
> What's your general pla
On 07/06/2012 05:05 PM, Catalin Marinas wrote:
> These patches are also available on this branch:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64.git
> upstream
Catalin,
What's your general plan for tracking development with this branch?
Jon.
--
To unsubscribe from th
On 07/17/2012 05:50 AM, Alan Cox wrote:
>> Right, I would say that with any CPU core more powerful than this one
>> or with more than a few of these, you will also have trouble coming
>> up with workloads that really require the CPU performance but don't
>> also require a 64 bit virtual address spa
On 07/17/2012 06:35 PM, Joe Perches wrote:
> On Tue, 2012-07-17 at 23:18 +0100, Catalin Marinas wrote:
>
>> The uname will still report
>> "aarch64" to match the compiler triplet and also avoid confusion of
>> existing 32-bit ARM scripts that simply check for "arm*" in the machine
>> name.
>
> Th
On Tue, 2012-07-17 at 23:18 +0100, Catalin Marinas wrote:
> The uname will still report
> "aarch64" to match the compiler triplet and also avoid confusion of
> existing 32-bit ARM scripts that simply check for "arm*" in the machine
> name.
The compiler triplet seems trivial to change.
The other
On Mon, Jul 16, 2012 at 12:53:21AM +0100, Linus Torvalds wrote:
> On Sun, Jul 15, 2012 at 4:21 PM, Måns Rullgård wrote:
> >
> > FWIW, I'd prefer naming the directory either arm64 or armv8 for a few
> > reasons:
> >
> > - Those are the names people actually use to refer to the architecture
> > - Th
Hi,
On Mon, Jul 16, 2012 at 01:16:51PM +0100, Pavel Machek wrote:
> > > > The AArch32 execution mode is optional, so it depends on the actual CPU
> > > > implementation (while AArch64 is mandatory). If the implementation
> > > > supports it, the most likely scenario for AArch32 at kernel level is
> Right, I would say that with any CPU core more powerful than this one
> or with more than a few of these, you will also have trouble coming
> up with workloads that really require the CPU performance but don't
> also require a 64 bit virtual address space in either user space
> or kernel.
There
On Tuesday 17 July 2012, Christoph Hellwig wrote:
> On Sun, Jul 15, 2012 at 07:43:07PM +, Arnd Bergmann wrote:
> > Yes, I agree that's the best way to handle this. Compared to other
> > architectures, I think x86 is the only that allows booting either a
> > 32 or 64 bit kernel on the same syste
On Tuesday 17 July 2012, Jon Masters wrote:
> On 07/16/2012 08:16 AM, Pavel Machek wrote:
>
> >> If an implementation supports AArch32 at EL3 there could be some
> >> physical (or some FPGA config) switch to choose between the two. But
> >> since AArch64 is mandated, I don't see why one would forc
On Mon, Jul 16, 2012 at 09:24:26AM +0100, Avi Kivity wrote:
> On 07/15/2012 03:16 PM, Catalin Marinas wrote:
> >
> > The AArch32 execution mode is optional, so it depends on the actual CPU
> > implementation (while AArch64 is mandatory). If the implementation
> > supports it, the most likely scena
On 07/16/2012 04:24 AM, Avi Kivity wrote:
> Can the same kernel image run in both EL1 and EL2? I noticed some .if
> ELs in the assembler files. I guess they could be compiled multiple
> times and the correct version chosen at runtime, or patched up like x86
> does with alternative().
> One of t
On 07/16/2012 08:16 AM, Pavel Machek wrote:
>> If an implementation supports AArch32 at EL3 there could be some
>> physical (or some FPGA config) switch to choose between the two. But
>> since AArch64 is mandated, I don't see why one would force AArch32 at
>> EL3 and therefore all lower exception
On Sun, Jul 15, 2012 at 07:43:07PM +, Arnd Bergmann wrote:
> Yes, I agree that's the best way to handle this. Compared to other
> architectures, I think x86 is the only that allows booting either a
> 32 or 64 bit kernel on the same system. We used to support 32 bit
> kernels on 64 bit PowerMac,
Pavel Machek writes:
> Hi!
>
>> The assembly syntax is very reasonable already and not far from what we
>> are used to (see the .S files in my kernel patches). The 64-bit
>> instructions are different and that's specified here (apart from the
>> actual bit encoding):
>>
>> http://infocenter.arm.
On Monday 16 July 2012, Pavel Machek wrote:
> > The assembly syntax is very reasonable already and not far from what we
> > are used to (see the .S files in my kernel patches). The 64-bit
> > instructions are different and that's specified here (apart from the
> > actual bit encoding):
> >
> > htt
Hi!
> The assembly syntax is very reasonable already and not far from what we
> are used to (see the .S files in my kernel patches). The 64-bit
> instructions are different and that's specified here (apart from the
> actual bit encoding):
>
> http://infocenter.arm.com/help/topic/com.arm.doc.genc0
Hi!
> > > The AArch32 execution mode is optional, so it depends on the actual CPU
> > > implementation (while AArch64 is mandatory). If the implementation
> > > supports it, the most likely scenario for AArch32 at kernel level is in
> > > virtual machines or the secure OS. I'll explain below why.
On Sun, Jul 15, 2012 at 9:43 PM, Arnd Bergmann wrote:
> Yes, I agree that's the best way to handle this. Compared to other
> architectures, I think x86 is the only that allows booting either a
> 32 or 64 bit kernel on the same system. We used to support 32 bit
> kernels on 64 bit PowerMac, but nob
On 07/15/2012 03:16 PM, Catalin Marinas wrote:
>
> The AArch32 execution mode is optional, so it depends on the actual CPU
> implementation (while AArch64 is mandatory). If the implementation
> supports it, the most likely scenario for AArch32 at kernel level is in
> virtual machines or the secure
On Sun, Jul 15, 2012 at 4:21 PM, Måns Rullgård wrote:
>
> FWIW, I'd prefer naming the directory either arm64 or armv8 for a few
> reasons:
>
> - Those are the names people actually use to refer to the architecture
> - They are more descriptive.
> - I think the official name is rather silly.
Agree
Catalin Marinas writes:
> On Tue, Jul 10, 2012 at 08:10:23AM +0100, Ingo Molnar wrote:
>> * Arnd Bergmann wrote:
>> > On Saturday 07 July 2012, Olof Johansson wrote:
>> > > > ARM introduced AArch64 as part of the ARMv8 architecture
>> > >
>> > > With the risk of bikeshedding here, but I find th
On Sun, Jul 15, 2012 at 08:43:07PM +0100, Arnd Bergmann wrote:
> On Sunday 15 July 2012, Catalin Marinas wrote:
> > The AArch32 execution mode is optional, so it depends on the actual CPU
> > implementation (while AArch64 is mandatory). If the implementation
> > supports it, the most likely scenari
On Sunday 15 July 2012, Catalin Marinas wrote:
> The AArch32 execution mode is optional, so it depends on the actual CPU
> implementation (while AArch64 is mandatory). If the implementation
> supports it, the most likely scenario for AArch32 at kernel level is in
> virtual machines or the secure OS
On Sat, Jul 14, 2012 at 10:30:32AM +0100, Pavel Machek wrote:
> > > > Agreed. It's clear from the code that it started out as a copy
> > > > of the 32 bit ARM code base, which I think was a mistake, but
> > > > it has also moved on since then and many areas of the 64 bit
> > > > code are now muc
On Sat, Jul 14, 2012 at 10:35:05AM +0100, Pavel Machek wrote:
> On Tue 2012-07-10 11:12:23, Catalin Marinas wrote:
> > On Sat, Jul 07, 2012 at 10:30:58AM +0100, Mikael Pettersson wrote:
> > > Catalin Marinas writes:
> > > > Compilation requires a new aarch64-none-linux-gnu-
> > > > toolchain (htt
On 07/10/2012 04:16 PM, Alexander Holler wrote:
> And it isn't so that the name will have to be used that seldom, at least
> every distribution would need to use it to name the flavour, like e.g.
> "Fedora AArch64hf" or "Debian AArch64".
The good news is we won't need an "hf" release because we
On Tue 2012-07-10 11:12:23, Catalin Marinas wrote:
> On Sat, Jul 07, 2012 at 10:30:58AM +0100, Mikael Pettersson wrote:
> > Catalin Marinas writes:
> > > Compilation requires a new aarch64-none-linux-gnu-
> > > toolchain (http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01694.html).
> >
> > Where ar
Hi!
> > > > With the risk of bikeshedding here, but I find the name awkward. How
> > > > about just naming the arch port arm64 instead? It's considerably more
> > > > descriptive in the context of the kernel. For reference, we didn't
> > > > name ppc64, nor powerpc, after what the IBM/power.org m
On Wed, 11 Jul 2012 11:53:35 +0100, Catalin Marinas
wrote:
> Hi Rusty,
Hi Catalin,
This is fun!
> On Wed, Jul 11, 2012 at 06:26:49AM +0100, Rusty Russell wrote:
> > I know it's a crazy idea, but why don't we try some actual analysis?
>
> This kind of analysis is not relevant. It's not
> What if they add 64-bit ARM support to arch/x86? AFAIK some of the
> machines are going to be basically PCs, including legacy I/O, ACPI
> and UEFI, so they are much closer to that than they are to anything
> in arch/arm. The instruction set of course is different, but you
> already said that this
Hi Rusty,
On Wed, Jul 11, 2012 at 06:26:49AM +0100, Rusty Russell wrote:
> On Tue, 10 Jul 2012 16:52:18 +, Arnd Bergmann wrote:
> > On Tuesday 10 July 2012, Alan Cox wrote:
> > > > In the AArch32 kernel port many implementation decisions newer
> > > > architectures were made in a way that pre
On Tue, Jul 10, 2012 at 10:44:29PM +0100, Catalin Marinas wrote:
> On Tue, Jul 10, 2012 at 09:35:27PM +0100, Ingo Molnar wrote:
> > Do you *really* think that all of the 32-bit ARM code should
> > essentially be thrown away when going to 64-bit ARM, that
> > patches can only touch arch/arm64/ + d
* Arnd Bergmann wrote:
> > Do you really think that all of the 32-bit ARM code should
> > essentially be thrown away when going to 64-bit ARM, that
> > patches can only touch arch/arm64/ + drivers/ or the
> > highway?
>
> Yes.
Straight answer ;-)
> If you're curious, please have a look at
On Tue, 10 Jul 2012 16:52:18 +, Arnd Bergmann wrote:
> On Tuesday 10 July 2012, Alan Cox wrote:
> > > In the AArch32 kernel port many implementation decisions newer
> > > architectures were made in a way that preserves backwards compatibility
> > > to over 15 years ago (and for good reasons, A
Once upon a time, Catalin Marinas said:
>Changing the arch/ dir name is easy at this point. My preference is for
>consistency with the official name (that cannot be changed) and the gcc
>triplet.
What ARM Ltd. says is the "official" name isn't necessarily what the
rest of the world will call it.
On Tue, Jul 10, 2012 at 10:19:38PM +0100, Arnd Bergmann wrote:
> On Tuesday 10 July 2012, Ingo Molnar wrote:
> > Do you really think that all of the 32-bit ARM code should
> > essentially be thrown away when going to 64-bit ARM, that
> > patches can only touch arch/arm64/ + drivers/ or the highwa
(just replying to a couple of points now, I'll follow up tomorrow)
On Tue, Jul 10, 2012 at 09:35:27PM +0100, Ingo Molnar wrote:
> Do you *really* think that all of the 32-bit ARM code should
> essentially be thrown away when going to 64-bit ARM, that
> patches can only touch arch/arm64/ + driver
On Tuesday 10 July 2012, Ingo Molnar wrote:
> So are you really convinced that the colorful ARM SoC world is
> not going to go 64-bit and will all unify behind a platform, and
> that we can actually force this process by not accepting
> non-generic patches? Is such a platform design being enforc
* Arnd Bergmann wrote:
> > What plans to other maintainers and board vendors have ? Any
> > design choice has to cope with these happening if a third
> > party goes and does it.
>
> It is slightly worrying to have multiple SoC vendors working
> on their own platform support. There are a few
Am 10.07.2012 19:14, schrieb Joe Perches:
On Tue, 2012-07-10 at 11:10 +0100, Catalin Marinas wrote:
On Tue, Jul 10, 2012 at 08:10:23AM +0100, Ingo Molnar wrote:
* Arnd Bergmann wrote:
On Saturday 07 July 2012, Olof Johansson wrote:
ARM introduced AArch64 as part of the ARMv8 architecture
W
On Tue, Jul 10, 2012 at 8:01 PM, Jan Ceuleers wrote:
> Perhaps it's a typo, and was meant to be AArgh64 :-)
Still a much better name than aarch64.
--
Thanks,
//richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.or
On 07/10/2012 07:14 PM, Joe Perches wrote:
> Count me as one of the 1000s that think it's a poor name choice.
> I think it's a poor name for marketing purposes too.
>
> Best of luck with whatever is used.
Perhaps it's a typo, and was meant to be AArgh64 :-)
--
To unsubscribe from this list: send
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
El Tue, 10 Jul 2012 11:10:18 +0100
Catalin Marinas escribió:
> On Tue, Jul 10, 2012 at 08:10:23AM +0100, Ingo Molnar wrote:
> > * Arnd Bergmann wrote:
> > > On Saturday 07 July 2012, Olof Johansson wrote:
> > > > > ARM introduced AArch64 as part of t
On Tue, 2012-07-10 at 11:10 +0100, Catalin Marinas wrote:
> On Tue, Jul 10, 2012 at 08:10:23AM +0100, Ingo Molnar wrote:
> > * Arnd Bergmann wrote:
> > > On Saturday 07 July 2012, Olof Johansson wrote:
> > > > > ARM introduced AArch64 as part of the ARMv8 architecture
> > > >
> > > > With the ris
On Tue, Jul 10, 2012 at 04:33:58PM +0100, Alan Cox wrote:
> > In the AArch32 kernel port many implementation decisions newer
> > architectures were made in a way that preserves backwards compatibility
> > to over 15 years ago (and for *good* reasons, ARMv4 hardware is still in
> > use). But keeping
On Tuesday 10 July 2012, Alan Cox wrote:
> > In the AArch32 kernel port many implementation decisions newer
> > architectures were made in a way that preserves backwards compatibility
> > to over 15 years ago (and for good reasons, ARMv4 hardware is still in
> > use). But keeping the same decisions
> In the AArch32 kernel port many implementation decisions newer
> architectures were made in a way that preserves backwards compatibility
> to over 15 years ago (and for *good* reasons, ARMv4 hardware is still in
> use). But keeping the same decisions in AArch64 is wrong.
Same argument as x86-32
On Tue, Jul 10, 2012 at 08:10:23AM +0100, Ingo Molnar wrote:
> * Arnd Bergmann wrote:
> > On Saturday 07 July 2012, Olof Johansson wrote:
> > > > ARM introduced AArch64 as part of the ARMv8 architecture
> > >
> > > With the risk of bikeshedding here, but I find the name awkward. How
> > > about j
On Sat, Jul 07, 2012 at 10:30:58AM +0100, Mikael Pettersson wrote:
> Catalin Marinas writes:
> > Compilation requires a new aarch64-none-linux-gnu-
> > toolchain (http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01694.html).
>
> Where are the corresponding binutils patches? Without those it's
> imp
* Arnd Bergmann wrote:
> On Saturday 07 July 2012, Olof Johansson wrote:
>
> > > ARM introduced AArch64 as part of the ARMv8 architecture
> >
> > With the risk of bikeshedding here, but I find the name awkward. How
> > about just naming the arch port arm64 instead? It's considerably more
> > d
On Monday 09 July 2012, Catalin Marinas wrote:
> On Mon, Jul 09, 2012 at 04:32:11PM +0100, Arnd Bergmann wrote:
> > We have a lot of reviewers that are familiar with the 32 bit code, so
> > I think the main strategy should be to spot duplicate code early
> > and make sure we deal with it individual
Arnd,
On Mon, Jul 09, 2012 at 04:32:11PM +0100, Arnd Bergmann wrote:
> We have a lot of reviewers that are familiar with the 32 bit code, so
> I think the main strategy should be to spot duplicate code early
> and make sure we deal with it individually. Examples for this are
> probably the impleme
On Mon, Jul 09, 2012 at 03:02:22PM +0100, Matthew Garrett wrote:
> On Mon, Jul 09, 2012 at 02:56:26PM +0100, Mark Brown wrote:
> > Where is this discussion?
> My part of it has pretty much been in-person discussion with Grant
> Likely, but there was some on ksummit-discuss last month.
Oh, I saw
> I think the main strategy should be to spot duplicate code early
> and make sure we deal with it individually. Examples for this are
> probably the implementations for kvm and perf, which largely deal
> with the same hardware on both architectures. Those definitely must
> not get duplicated into
On Monday 09 July 2012, Alan Cox wrote:
> > > These are the same reasons the x86_64 people gave and regretted later.
> >
> > I would not compare the x86_64 extension to the AArch64 architecture.
>
>
> It's not an architecture specific observation. I was just observing that
> you were following a
On Mon, Jul 09, 2012 at 02:56:26PM +0100, Mark Brown wrote:
> On Mon, Jul 09, 2012 at 02:06:29PM +0100, Matthew Garrett wrote:
>
> > There's ongoing discussion about unifying ACPI and ftd representation,
> > and once that's done this isn't a problem, but right now there's no
>
> Where is this d
On Mon, Jul 09, 2012 at 02:06:29PM +0100, Matthew Garrett wrote:
> There's ongoing discussion about unifying ACPI and ftd representation,
> and once that's done this isn't a problem, but right now there's no
Where is this discussion?
> terribly straightforward way to do this without a lot of b
> > These are the same reasons the x86_64 people gave and regretted later.
>
> I would not compare the x86_64 extension to the AArch64 architecture.
It's not an architecture specific observation. I was just observing that
you were following a pattern which in all other cases ended up with a
merg
On Mon, Jul 9, 2012 at 4:01 AM, Jon Masters wrote:
> On 07/08/2012 06:24 PM, Dennis Gilmore wrote:
>> I know that the architecture really is new but thats not really clear
>> by adding AArch32 into the mix to represent 32 bit arm as ARM has done
>> or by calling it armv8. There is enough way to co
On Mon, Jul 09, 2012 at 01:32:56PM +0100, Mark Brown wrote:
> If you end up having to write two whole drivers that sounds enormously
> depressing especially for those of us working on devices that aren't
> architecture specific. We've managed to avoid that thus far with device
> tree and platform
On Sat, Jul 07, 2012 at 04:29:08AM +0100, Matthew Garrett wrote:
> While mandating FDT is a massive advance over arm32, if there's a chance
> that ACPI-based AArch64 platforms will ship in a similar timeframe to
> FDT then I think we should ensure that ACPI and FDT are merged
> beforehand - the
On Sunday 2012-07-08 12:18, Catalin Marinas wrote:
>
>On the good side, alphabetically it's before arch/alpha, so easier to
>grep.
And during `ls -l`, it'll happily scroll off the screen into oblivion :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a m
Hi Alan,
On Sun, Jul 08, 2012 at 12:29:20AM +0100, Alan Cox wrote:
> > 1. The AArch64 architecture is significantly different from AArch32 (the
> > official name of the 32-bit ARM architecture), it is not an extension.
> > It has a new exception model, new instruction set (even the register
> > na
Hi Jon,
On 9 July 2012 03:01, Jon Masters wrote:
> On 07/08/2012 06:24 PM, Dennis Gilmore wrote:
>> I know that the architecture really is new but thats not really clear
>> by adding AArch32 into the mix to represent 32 bit arm as ARM has done
>> or by calling it armv8. There is enough way to con
On 07/08/2012 06:24 PM, Dennis Gilmore wrote:
> I know that the architecture really is new but thats not really clear
> by adding AArch32 into the mix to represent 32 bit arm as ARM has done
> or by calling it armv8. There is enough way to confuse them already why
> confuse things more by adding y
On 07/08/2012 04:31 PM, Jan Engelhardt wrote:
>
> On Sunday 2012-07-08 09:54, Jon Masters wrote:
>>
>> FWIW I actually really like the aarch64 name (but you know that already
>> :) ). I think it clearly spells out that this is not just a 64-bit
>> extension to the existing 32-bit ARM Architecture,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sun, 08 Jul 2012 14:31:05 -0400
Jon Masters wrote:
> On 07/08/2012 03:54 AM, Jon Masters wrote:
>
> > In our bikeshedding conversations pondering future Fedora support,
> > we've pretty much settled on the aarch64 name now, and the hope is
> > th
On Sunday 2012-07-08 09:54, Jon Masters wrote:
>
>FWIW I actually really like the aarch64 name (but you know that already
>:) ). I think it clearly spells out that this is not just a 64-bit
>extension to the existing 32-bit ARM Architecture, it is a new (inspired
>by ARM) architecture.
IA64 also
On Sunday 2012-07-08 07:05, Henrique de Moraes Holschuh wrote:
>>>
>>>I agree the name sucks, and I'd much prefer to just call it arm64 as
>>>well. The main advantage of the aarch64 name is that it's the same
>>>as the identifier in the elf triplet, [...] to identify the
>>>architecture, [...] the
On 07/08/2012 03:54 AM, Jon Masters wrote:
> In our bikeshedding conversations pondering future Fedora support, we've
> pretty much settled on the aarch64 name now, and the hope is that we can
> also avoid providing 32-bit compatibility (multi-arch) by relying on
> virtualized guests for any 32-bi
On 07/08/2012 07:17 AM, Dr. David Alan Gilbert wrote:
> * Jon Masters (j...@redhat.com) wrote:
>> On 07/07/2012 03:27 PM, Arnd Bergmann wrote:
>>> On Saturday 07 July 2012, Olof Johansson wrote:
>>>
> ARM introduced AArch64 as part of the ARMv8 architecture
With the risk of bikesheddi
* Jon Masters (j...@redhat.com) wrote:
> On 07/07/2012 03:27 PM, Arnd Bergmann wrote:
> > On Saturday 07 July 2012, Olof Johansson wrote:
> >
> >>> ARM introduced AArch64 as part of the ARMv8 architecture
> >>
> >> With the risk of bikeshedding here, but I find the name awkward. How
> >> about jus
Hi Olof,
On Sat, Jul 07, 2012 at 04:53:08AM +0100, Olof Johansson wrote:
> On Fri, Jul 6, 2012 at 2:05 PM, Catalin Marinas
> wrote:
> > ARM introduced AArch64 as part of the ARMv8 architecture
>
> With the risk of bikeshedding here, but I find the name awkward. How
> about just naming the arch p
On 07/07/2012 03:27 PM, Arnd Bergmann wrote:
> On Saturday 07 July 2012, Olof Johansson wrote:
>
>>> ARM introduced AArch64 as part of the ARMv8 architecture
>>
>> With the risk of bikeshedding here, but I find the name awkward. How
>> about just naming the arch port arm64 instead? It's considerab
On Sun, 08 Jul 2012, Jan Engelhardt wrote:
> On Saturday 2012-07-07 21:27, Arnd Bergmann wrote:
> >On Saturday 07 July 2012, Olof Johansson wrote:
> >> > ARM introduced AArch64 as part of the ARMv8 architecture
> >>
> >> With the risk of bikeshedding here, but I find the name awkward. How
> >> abo
On Saturday 2012-07-07 21:27, Arnd Bergmann wrote:
>On Saturday 07 July 2012, Olof Johansson wrote:
>
>> > ARM introduced AArch64 as part of the ARMv8 architecture
>>
>> With the risk of bikeshedding here, but I find the name awkward. How
>> about just naming the arch port arm64 instead?
>
>I agr
On Saturday 2012-07-07 05:53, Olof Johansson wrote:
>
>> ARM introduced AArch64 as part of the ARMv8 architecture
>
>With the risk of bikeshedding here, but I find the name awkward. How
>about just naming the arch port arm64 instead? It's considerably more
>descriptive in the context of the kernel
> 1. The AArch64 architecture is significantly different from AArch32 (the
> official name of the 32-bit ARM architecture), it is not an extension.
> It has a new exception model, new instruction set (even the register
> names are different), new C ABI, PCS. It has a hardware compat mode but
> tha
On Fri, Jul 06, 2012 at 11:58:04PM +0100, Alan Cox wrote:
> > arch/x86/include/asm/atomic64_32.h |1 +
> > arch/x86/include/asm/atomic64_64.h |1 +
> > arch/xtensa/kernel/syscall.c|2 +-
>
> This looks odd to say the least ?
There are a fe
On Friday 06 July 2012, Alan Cox wrote:
> > arch/x86/include/asm/atomic64_32.h |1 +
> > arch/x86/include/asm/atomic64_64.h |1 +
> > arch/xtensa/kernel/syscall.c|2 +-
>
> This looks odd to say the least ?
See patch 1/36. I think it makes
On Sat, Jul 07, 2012 at 11:30:58AM +0200, Mikael Pettersson wrote:
> Catalin Marinas writes:
> > Compilation requires a new aarch64-none-linux-gnu-
> > toolchain (http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01694.html).
>
> Where are the corresponding binutils patches? Without those it's
> imp
On Saturday 07 July 2012, Olof Johansson wrote:
> > ARM introduced AArch64 as part of the ARMv8 architecture
>
> With the risk of bikeshedding here, but I find the name awkward. How
> about just naming the arch port arm64 instead? It's considerably more
> descriptive in the context of the kernel.
Catalin Marinas writes:
> Compilation requires a new aarch64-none-linux-gnu-
> toolchain (http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01694.html).
Where are the corresponding binutils patches? Without those it's
impossible for people outside ARM to build the toolchain and kernel.
/Mikael
--
T
Catalin,
On Fri, Jul 6, 2012 at 2:05 PM, Catalin Marinas wrote:
> This set of patches implements the core Linux support for the AArch64
> (64-bit ARM) architecture.
Hmm. I didn't see a cc to current ARM maintainer (Russell), nor did
you cc the topic list that you list in the MAINTAINERS entry. I
On Fri, Jul 06, 2012 at 10:05:41PM +0100, Catalin Marinas wrote:
> There is no hardware platform available at this point. From a kernel
> perspective, the aim is to minimise (or even completely remove) the
> platform code from the architecture specific directory. FDT is currently
> mandated and th
> arch/x86/include/asm/atomic64_32.h |1 +
> arch/x86/include/asm/atomic64_64.h |1 +
> arch/xtensa/kernel/syscall.c|2 +-
This looks odd to say the least ?
The only other question I'd ask is given that ppc and x86 have both done
32/64bit
This set of patches implements the core Linux support for the AArch64
(64-bit ARM) architecture.
ARM introduced AArch64 as part of the ARMv8 architecture and consists of
a substantially revised exception model (with 4 exception levels: EL0 -
user, EL1 - kernel, EL2 - hypervisor, EL3 - secure moni
95 matches
Mail list logo
