В Thu, 3 Apr 2014 11:37:05 -0700
Ram Pai <linux...@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 <linux...@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
>
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
