Hi all, I'm trying to understand the valid values for our various "architecture" variables in MasterInclude.mk (ARCH, KARCHS, GNU_ARCH, GNU_TUNE) in the context of cross-compiled builds.
I'm OK with GNU_ARCH and GNU_TUNE because I can see those are driving the setting of -march and -mtune for GCC and they are covered in the GCC documentation (http://gcc.gnu.org/onlinedocs/gcc/Submodel-Options.html) For Bering-uClibc 4.x our make/MasterInclude.mk specifies: -march=$(GNU_ARCH) -mtune=$(GNU_TUNE) where: $(GNU_ARCH) = i486 $(GNU_TUNE) = pentiumpro Then there is KARCHS, where we have multiple variants (i686, i486, geode). This is effectively just a way to have different Kernels based on different Kernel .config settings, and hence different kernel Modules and different Initrd files. I'm OK with this since I understand how we added support for KARCHS in Bering-uClibc 4.x and how the Kernel .config patching works. In the Kernel .config we have settings like CONFIG_M686=y, for i686. The bit I don't understand (or at least didn't, until I started composing this mail, several hours ago) is ARCH, which is set to "i386" for Bering-uClibc 4.x. Based on my investigations today it looks like ARCH is fundamentally a Kernel configuration setting and the value of ARCH must match the name of a directory under e.g. linux-3.2.11/arch/ - with a couple of special cases accommodated in linux-3.2.11/Makefile, for example i386 and x86_64 both relate to directory linux-3.2.11/arch/x86/. Within the Kernel .config for ARCH:=i386 we have CONFIG_X86=y and then some adjustments for i686, geode etc. as part of KARCHS. There is also an "architecture" selection for uClibc which we seem to match to the value of ARCH. For Bering-uClibc 4.x we configure uClibc with TARGET_ARCH=i386 but we also specify TARGET_SUBARCH=i486 and CONFIG_486=y. That means that our "i386" toolchain is actually an *i486* toolchain, which I think we all understand and we accept that we only build one set of LRP executables for x86 devices. My primary motivation is to understand what all these variables should be set to for non-x86 platforms such as ARM. For example the Raspberry Pi has a Broadcom BCM2835 chip containing an ARM1176JZFS CPU. That is part of the ARM11 processor family built on the ARMv6 architecture, so for GCC we'd want to set -march=armv6 (or possibly -march=armv6zk) and then maybe -mtune=arm1176jzf-s. In terms of Kernel configuration we'd want to specify ARCH:=ARM (and hence CONFIG_ARM=y) and then CONFIG_ARCH_BCMRING=y (which looks to be the equivalent of e.g. CONFIG_M686=y or CONFIG_MGEODE_LX=y so would be configured via KARCHS). I'm therefore thinking, for the Raspberry Pi: ARCH = arm KARCHS = bcmring GNU_ARCH = armv6 GNU_TUNE = arm1176jzf-s In the uClibc .config I'd want to set TARGET_arm=y, TARGET_ARCH="arm" and CONFIG_ARM1176JZF_S=y (which then compiles uClibc with -march=armv6 and -mtune=arm1176jzf-s based on the settings in Rules.mak). That means we'd have an "armv6" toolchain rather than a generic "arm" toolchain. I'm also thinking about what the "ARCH" arguments to buildtool.pl and buildpacket.pl should look like. Maybe we just use the GCC "target triplet" syntax, so e.g. i486-pc-linux-uclibc for the Bering-uClibc 4.x platform armv6-unknown-linux-uclibc for the Raspberry pi In other words, "buildtool.pl --target=i486-pc-linux-uclibc build ..." rather than "buildtool.pl --arch=i386 build ..." Thoughts? David ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
