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. > > 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
