From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1WVmvY-0005rj-1Y for mharc-grub-devel@gnu.org; Thu, 03 Apr 2014 15:03:52 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57108) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WVmvN-0005rV-Ne for grub-devel@gnu.org; Thu, 03 Apr 2014 15:03:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WVmvE-0002Sx-LB for grub-devel@gnu.org; Thu, 03 Apr 2014 15:03:41 -0400 Received: from mail-la0-x22c.google.com ([2a00:1450:4010:c03::22c]:33421) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WVmvE-0002Sr-7t for grub-devel@gnu.org; Thu, 03 Apr 2014 15:03:32 -0400 Received: by mail-la0-f44.google.com with SMTP id c6so1693150lan.17 for ; Thu, 03 Apr 2014 12:03:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; bh=KC4ar4OZccnT/372jmbG9Wo+sgdOiDUZJw0TLwRANCM=; b=lKHzcvTgfdX0C7fpp5giMq3IiQwNfbrZ1bbXld/sa00cUq2kxDDWCi3M5aMUd6zdTr F/kvA6j6+dgS0ySOV8bnKsIUmc33gpV6TXnisbU0DG7lbKpVRMTSyKpa1kjV4au7ODk7 7skaBurl0Yl2bn9Dq1Lp3my+zG030P3lgrNoIHuoLyTdc4ExXfA5oaII9ec031WdBLPy 8eDwWlr3x1rGKl1FUyJhEc/6yitA7CJGzWlZg4rOqoE28ZQQVArebPxjy5UknQ1WXR6e wzqsMJuWi0e55c1wtY4pRPEJtwAffwWUYBhAKihAy2eAM4zQ6CoBlvg3PiXzdsS0RD1F QIRQ== X-Received: by 10.152.23.200 with SMTP id o8mr47631laf.80.1396551811128; Thu, 03 Apr 2014 12:03:31 -0700 (PDT) Received: from opensuse.site (ppp37-190-15-130.pppoe.spdop.ru. [37.190.15.130]) by mx.google.com with ESMTPSA id wm1sm5609021lac.14.2014.04.03.12.03.30 for (version=SSLv3 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 03 Apr 2014 12:03:30 -0700 (PDT) Date: Thu, 3 Apr 2014 23:03:29 +0400 From: Andrey Borzenkov To: Ram Pai Subject: Re: [RFC PATCH 21/23] powerpc64 is not necessarily BigEndian anymore! :) Message-ID: <20140403230329.06d61900@opensuse.site> In-Reply-To: <20140403183705.GK29218@ram.oc3035372033.ibm.com> References: <1393439482-20341-1-git-send-email-linuxram@us.ibm.com> <1393439482-20341-22-git-send-email-linuxram@us.ibm.com> <20140401214945.209b4894@opensuse.site> <533B1FF2.9040503@gmail.com> <20140403173336.GA16534@ram.oc3035372033.ibm.com> <20140403215356.1b953172@opensuse.site> <20140403183705.GK29218@ram.oc3035372033.ibm.com> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.22; x86_64-suse-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c03::22c Cc: The development of GNU GRUB , pfsmorigo@br.ibm.com, phcoder@gmail.com X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 19:03:51 -0000 =D0=92 Thu, 3 Apr 2014 11:37:05 -0700 Ram Pai =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > On Thu, Apr 03, 2014 at 09:53:56PM +0400, Andrey Borzenkov wrote: > > =D0=92 Thu, 3 Apr 2014 10:33:36 -0700 > > Ram Pai =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > >=20 > > > On Tue, Apr 01, 2014 at 10:22:10PM +0200, Vladimir '=CF=86-coder/phco= der' Serbinenko wrote: > > > >=20 > > > > >=20 > > > > > For the sake of bisectability this really should be moved earlier; > > > > > otherwise at least patch "fix parameter to firmware calls" would > > > > > be wrong. > > > > >=20 > > > > Even bigger problem is whether we want to run in LE mode at all. Fr= om > > > > 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. > > >=20 > > > Yes. firmware runs in 32bit BE mode. And there is a constant switch f= rom > > > 64bit LE to 32bit BE and vice-versa for each firmware call. > > >=20 > > > > doing firmware calls. Byteswapping for the purpose of firmware call= s 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)=20 > > >=20 > > > 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. > > >=20 > > >=20 > > > > 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=3D-EL). > > >=20 > >=20 > > Hmm ... gcc docs mention this only for MIPS, not for PowerPC; for > > PowerPC it says -mbig. > >=20 > > > Well. that is the issue. Various distros have varied support for > > > cross-compilation (multi-arch support). If the distro does not=20 > > > have 32bit BE libraries natively installed (out-of-the-box), they > > > wont be able to generate a 32bit BE grub loader. > >=20 > > We speak only about target code that runs at boot time. This code does > > not use any library.=20 >=20 > I am not a compiler/toolchain expert. But dont we need all the necessary > tools and libraries in /lib/--linux/ directory for cross > compilation; even to generate static executables? >=20 > > 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*? >=20 > 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. >=20 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 :=3D -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=3Dinclude) \ -mbig-endian > >=20 > > 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). > >=20 > > > These set of patches > > > overcomes the deficiency by generating a working native executable=20 > > > on LE systems. > > >=20 > > > > So it looks like this patch series adds a new high-maintenance-cost= port > > > > covering only already supported machines and already supportred fea= tures. > > >=20 > > > It does add maintainence; I agree. But than it does overcome some > > > deficiences aswell. > > >=20 > >=20 > > Do you mean there are some problems with big-endian code at boot time? > > Could you give more details? >=20 > 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)=20 > available on the distro. >=20 >=20 > RP >=20