linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Russell King - ARM Linux admin <linux@armlinux.org.uk>
Cc: Will Deacon <will@kernel.org>,
	Anders Roxell <anders.roxell@linaro.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	John Garry <john.garry@huawei.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Olof Johansson <olof@lixom.net>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Chunrong Guo <chunrong.guo@nxp.com>
Subject: Re: [PATCH 3/3] arm64: configs: unset CPU_BIG_ENDIAN
Date: Sat, 12 Oct 2019 00:47:45 +0200	[thread overview]
Message-ID: <CAK8P3a1ADTc0woWWNjpeqYEtgb=snj264P4QNWOj7ZRMDv8WNg@mail.gmail.com> (raw)
In-Reply-To: <20191011103342.GL25745@shell.armlinux.org.uk>

On Fri, Oct 11, 2019 at 12:33 PM Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
>
> On Fri, Oct 11, 2019 at 11:27:48AM +0100, Will Deacon wrote:
> > Does anybody use BIG_ENDIAN? If we're not even building it then maybe we
> > should get rid of it altogether on arm64. I don't know of any supported
> > userspace that supports it or any CPUs that are unable to run little-endian
> > binaries.

So far, all 'allmodconfig' builds are big-endian and have been that way
since the option was first added, so build coverage is something we
have plenty of. It's also covered by randconfig testing, regardless of
the default endianess.

> 32-bit ARM experience is that telco class users really like big
> endian.

Right, basically anyone with a large code base migrated over from a
big-endian MIPS or PowerPC legacy that found it cheaper to change
the rest of the world than to fix their own code. The only other example
of this I heard of besides networking was from banking, where they
looked at moving from AIX on PowerPC to Linux on something cheaper,
but IIRC they ended up going with LE after all because of the lack
of distro support.

Whether any users remain in use at this time, I don't know. As most
of the larger machines require UEFI to boot, they are currently limited
to little-endian for all practical purposes, and smaller embedded
machines tend to have a smaller amount of legacy code and are
easier to move over to little-endian.

One recent reference I could find is specifically for the NXP
Layerscape LS1043 in
https://www.nxp.com/docs/en/application-note/AN5129.pdf
which apparently has some support in their codewarrior tools
for big-endian binaries.

There are also some recent openembedded bugfixes for
big-endian arm64 from NXP:
https://www.mail-archive.com/meta-freescale@yoctoproject.org/msg22378.html

Adding Chungrong Guo to Cc for additional insight on whether
they expect any notable big-endian users in the future.

      Arnd

  reply	other threads:[~2019-10-11 22:48 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-26 19:30 [PATCH 0/3] arm64: defconfig: set/unset for allmodconfig Anders Roxell
2019-09-26 19:30 ` [PATCH 1/3] arm64: configs: defconfig: enable DEBUG_PREEMPT and FTRACE Anders Roxell
2019-09-26 19:30 ` [PATCH] arm64: configs: defconfig: remove unneeded fragments Anders Roxell
2019-09-26 19:30 ` [PATCH 2/3] arm64: configs: unset CMDLINE_FORCE Anders Roxell
2019-10-15  8:38   ` John Garry
2019-09-26 19:30 ` [PATCH 3/3] arm64: configs: unset CPU_BIG_ENDIAN Anders Roxell
2019-10-01 14:04   ` John Garry
2019-10-03  7:40     ` Anders Roxell
2019-10-03 11:15       ` John Garry
2019-10-11 10:25         ` Arnd Bergmann
2019-10-11 10:27           ` Will Deacon
2019-10-11 10:33             ` Russell King - ARM Linux admin
2019-10-11 22:47               ` Arnd Bergmann [this message]
2019-10-12 14:50                 ` Russell King - ARM Linux admin
2019-10-14 16:24                   ` Will Deacon
2019-10-15  3:13                     ` Hanjun Guo
2019-10-12  7:33             ` Hanjun Guo
2019-10-12 14:05               ` Arnd Bergmann
2019-10-14  6:12                 ` Hanjun Guo
2019-10-14 16:20                 ` Will Deacon
2019-10-14 10:58 ` [PATCH 0/3] arm64: defconfig: set/unset for allmodconfig John Garry

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='CAK8P3a1ADTc0woWWNjpeqYEtgb=snj264P4QNWOj7ZRMDv8WNg@mail.gmail.com' \
    --to=arnd@arndb.de \
    --cc=anders.roxell@linaro.org \
    --cc=catalin.marinas@arm.com \
    --cc=chunrong.guo@nxp.com \
    --cc=john.garry@huawei.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=olof@lixom.net \
    --cc=will@kernel.org \
    /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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).