grub-devel.gnu.org archive mirror
 help / color / mirror / Atom feed
From: Andrey Borzenkov <arvidjaar@gmail.com>
To: Ram Pai <linuxram@us.ibm.com>
Cc: The development of GNU GRUB <grub-devel@gnu.org>,
	pfsmorigo@br.ibm.com, phcoder@gmail.com
Subject: Re: [RFC PATCH 21/23] powerpc64 is not necessarily BigEndian anymore! :)
Date: Thu, 3 Apr 2014 23:03:29 +0400	[thread overview]
Message-ID: <20140403230329.06d61900@opensuse.site> (raw)
In-Reply-To: <20140403183705.GK29218@ram.oc3035372033.ibm.com>

В Thu, 3 Apr 2014 11:37:05 -0700
Ram Pai <linuxram@us.ibm.com> пишет:

> On Thu, Apr 03, 2014 at 09:53:56PM +0400, Andrey Borzenkov wrote:
> > В Thu, 3 Apr 2014 10:33:36 -0700
> > Ram Pai <linuxram@us.ibm.com> пишет:
> > 
> > > On Tue, Apr 01, 2014 at 10:22:10PM +0200, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> > > > 
> > > > > 
> > > > > For the sake of bisectability this really should be moved earlier;
> > > > > otherwise at least patch "fix parameter to firmware calls" would
> > > > > be wrong.
> > > > > 
> > > > Even bigger problem is whether we want to run in LE mode at all. From
> > > > what I understand (correct if I'm wrong) firmware calls remain
> > > > big-endian and you need to switch back and forth between LE and BE when
> > > > doing firmware calls.
> > > 
> > > Yes. firmware runs in 32bit BE mode. And there is a constant switch from
> > > 64bit LE to 32bit BE and vice-versa for each firmware call.
> > > 
> > > > doing firmware calls. Byteswapping for the purpose of firmware calls is
> > > > to be avoided as bugs are easy to slip through (in fact the
> > > > byte-swapping isn't complete in proposed patches.
> > > > (correct me if I'm wrong) 
> > > 
> > > Is that true? maybe you are right. I might have missed something.
> > > However please hint me what i have missed. I will look into some
> > > other arch code that support the same ieee platform.
> > > 
> > > 
> > > > these new patches cover a subset of already
> > > > supported machines and don't add any user-visible feature and no new
> > > > kernel type (LE kernel can be loaded from BE GRUB).
> > > > Cross-compiling to BE from LE is easy (TARGET_CFLAGS=-EL).
> > > 
> > 
> > Hmm ... gcc docs mention this only for MIPS, not for PowerPC; for
> > PowerPC it says -mbig.
> > 
> > > Well. that is the issue.  Various distros have varied support for
> > > cross-compilation (multi-arch support). If the distro does not 
> > > have 32bit BE libraries natively installed (out-of-the-box), they
> > > wont be able to generate a 32bit BE grub loader.
> > 
> > We speak only about target code that runs at boot time. This code does
> > not use any library. 
> 
> I am not a compiler/toolchain expert. But dont we need all the necessary
> tools and libraries in /lib/<arch>-<dist>-linux/ directory for cross
> compilation; even to generate static executables?
> 
> > It only needs compiler support. GRUB does not
> > support anything besides gcc and recently some clang support was added.
> > Do you have real life example of distribution which does not support
> > -mbig gcc option to produce big-endian *code*?
> 
> This is ideally what I want too. But it is not possible
> **out-of-the-box** on any distro for power arch.  I am told
> that debian has a new multi-arch support added which makes this
> work out-of-the-box, but it is still in early stages to work
> seemlessly **out-of-the-box**. I may be wrong.
> 

If distribution is capable of building Linux kernel, it should be
capable of compiling 32 bit big-endian code. Linux startup code on
PowerPC is built as 32 bit big-endian:

BOOTCFLAGS    := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
                 -fno-strict-aliasing -Os -msoft-float -pipe \
                 -fomit-frame-pointer -fno-builtin -fPIC -nostdinc \
                 -isystem $(shell $(CROSS32CC) -print-file-name=include) \
                 -mbig-endian


> > 
> > It is perfectly legal to have different architectures for host and
> > target. So you will have little-endian 64 bit host tools and big-endan
> > 32 bit target. If this works for you this of course is much better
> > solution (at the end it requires just a single line in configure.ac).
> > 
> > >                                                 These set of patches
> > > overcomes the deficiency by generating a working native executable 
> > > on LE systems.
> > > 
> > > > So it looks like this patch series adds a new high-maintenance-cost port
> > > > covering only already supported machines and already supportred features.
> > > 
> > > It does add maintainence; I agree. But than it does overcome some
> > > deficiences aswell.
> > > 
> > 
> > Do you mean there are some problems with big-endian code at boot time?
> > Could you give more details?
> 
> No there is absolutely no problem with big endian code at boot time.
> I am talking about the challenges faced in cross compiling, if the
> necessary multiarch/multilib support is not natively(out-of-the-box) 
> available on the distro.
> 
> 
> RP
> 



  reply	other threads:[~2014-04-03 19:03 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-26 18:30 [RFC PATCH 00/23] grub 64bit little-endian on power Ram Pai
2014-02-26 18:31 ` [RFC PATCH 01/23] Add a new architecture to the build process Ram Pai
2014-02-26 18:31 ` [RFC PATCH 02/23] Build LE grub as O1 Ram Pai
2014-02-26 18:31 ` [RFC PATCH 03/23] ignore .TOC. symbol Ram Pai
2014-04-01 16:52   ` Andrey Borzenkov
2014-02-26 18:31 ` [RFC PATCH 04/23] grub-install can now recognize and install a LE grub boot loader Ram Pai
2014-02-26 18:31 ` [RFC PATCH 05/23] set ABI version in e_flag of the PPC64LE ELF image Ram Pai
2014-02-26 18:31 ` [RFC PATCH 06/23] Add IEEE1275_ADDR helper Ram Pai
2014-04-01 17:11   ` Andrey Borzenkov
2014-02-26 18:31 ` [RFC PATCH 07/23] Fix some more warnings when casting Ram Pai
2014-02-26 18:31 ` [RFC PATCH 08/23] Add powerpc64 types Ram Pai
2014-04-01 17:15   ` Andrey Borzenkov
2014-04-02 17:02     ` Ram Pai
2014-02-26 18:31 ` [RFC PATCH 09/23] Fix warnings when building powerpc linux loader 64bit Ram Pai
2014-04-01 17:21   ` Andrey Borzenkov
2014-04-02 17:03     ` Ram Pai
2014-02-26 18:31 ` [RFC PATCH 10/23] GRUB_ELF_R_PPC_* processing is applicable only for 32 bit bootloader Ram Pai
2014-02-26 18:31 ` [RFC PATCH 11/23] Fix powerpc setjmp/longjmp 64bit issues Ram Pai
2014-04-01 17:27   ` Andrey Borzenkov
2014-04-02 17:06     ` Ram Pai
2014-04-02 17:19       ` Andrey Borzenkov
2014-04-02 17:48         ` Ram Pai
2014-04-02 17:56           ` Andrey Borzenkov
2014-04-02 18:55             ` Ram Pai
2014-02-26 18:31 ` [RFC PATCH 12/23] Add powerpc64 ieee1275 trampoline Ram Pai
2014-02-26 18:31 ` [RFC PATCH 13/23] Add 64bit support to powerpc startup code Ram Pai
2014-02-26 18:31 ` [RFC PATCH 14/23] Add grub_dl_find_section_addr Ram Pai
2014-02-26 18:31 ` [RFC PATCH 15/23] Add ppc64 relocations Ram Pai
2014-02-26 18:31 ` [RFC PATCH 16/23] ppc64 doesn't need libgcc routines Ram Pai
2014-02-26 18:31 ` [RFC PATCH 17/23] Use FUNC_START/FUNC_END for powerpc function definitions Ram Pai
2014-02-26 18:31 ` [RFC PATCH 18/23] .TOC. symbol is special in ppc64le Ram Pai
2014-02-26 18:31 ` [RFC PATCH 19/23] align .toc section on 4byte boundary Ram Pai
2014-02-26 18:31 ` [RFC PATCH 20/23] fix parameter to firmware calls Ram Pai
2014-04-01 17:45   ` Andrey Borzenkov
2014-04-02 17:08     ` Ram Pai
2014-04-02 17:16       ` Andrey Borzenkov
2014-02-26 18:31 ` [RFC PATCH 21/23] powerpc64 is not necessarily BigEndian anymore! :) Ram Pai
2014-04-01 17:49   ` Andrey Borzenkov
2014-04-01 20:22     ` Vladimir 'φ-coder/phcoder' Serbinenko
2014-04-03 17:33       ` Ram Pai
2014-04-03 17:53         ` Andrey Borzenkov
2014-04-03 18:37           ` Ram Pai
2014-04-03 19:03             ` Andrey Borzenkov [this message]
2014-04-03 19:26               ` Ram Pai
2014-04-03 19:42                 ` Vladimir 'φ-coder/phcoder' Serbinenko
2014-04-03 20:23                   ` Ram Pai
2014-04-03 19:54                 ` Andrey Borzenkov
2014-04-03 20:32                   ` Ram Pai
2014-04-03 21:41                     ` Vladimir 'phcoder' Serbinenko
2014-04-04  2:28                     ` Andrey Borzenkov
2014-04-04 17:47                       ` Ram Pai
2014-04-04 18:17                         ` Andrey Borzenkov
2014-04-04 18:24                           ` Dinar Valeev
2014-04-04 19:12                             ` Andrey Borzenkov
2014-04-04 20:29                               ` Dinar Valeev
2014-04-04 22:19                                 ` Ram Pai
     [not found]                                   ` <CAEaD8JN9SkqU9+BkU2MYub=aC3Wb143nMPgRWjVbFvgit90yBQ@mail.gmail.com>
2014-04-05  0:04                                     ` Fwd: " Vladimir 'phcoder' Serbinenko
2014-09-27  5:42                             ` Andrei Borzenkov
2014-09-28  6:33                               ` Andrei Borzenkov
2014-04-04  6:37                   ` Vladimir 'φ-coder/phcoder' Serbinenko
2014-04-04 17:08                     ` Andrey Borzenkov
2014-04-05 15:45                       ` Vladimir 'φ-coder/phcoder' Serbinenko
2014-04-05 16:49                         ` Andrey Borzenkov
2014-04-05 18:29                           ` Vladimir 'φ-coder/phcoder' Serbinenko
2014-04-05 18:48                             ` Andrey Borzenkov
2014-04-02 17:09     ` Ram Pai
2014-02-26 18:31 ` [RFC PATCH 22/23] fix segfaults if initrd Ram Pai
2014-02-26 18:31 ` [RFC PATCH 23/23] Optional: Power7 VSX instructions workaround Ram Pai

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=20140403230329.06d61900@opensuse.site \
    --to=arvidjaar@gmail.com \
    --cc=grub-devel@gnu.org \
    --cc=linuxram@us.ibm.com \
    --cc=pfsmorigo@br.ibm.com \
    --cc=phcoder@gmail.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: 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).