From: davidMbrooke <le...@da...> - 2012-03-18 17:44:38
|
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 |
From: Andrew <ni...@se...> - 2012-03-18 21:59:20
|
18.03.2012 19:44, davidMbrooke пишет: > 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. Hi. ARCH defines for what ARCH is cross-compiled kernel (ARCH=$(ARCH) make). It needs to be specified because in other case make oldconfig/make menuconfig will try to change settings for current host arch. KARCHS - list of kernel variants (and related modules). IMHO it should be unique for each embedded platform/family of very similar platforms. GNU_ARCH - CPU type for which userland is built, GNU_TUNE - for which CPU variant userland will be optimized (because userland will run on different CPU sub-archs). > > 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 AFAIK there is no difference between '-pc-linux-uclibc' and '-unknown-linux-uclibc' suffixes, and IMHO it'll be safe to use i486-unknown-linux-uclibc arch. |
From: davidMbrooke <le...@da...> - 2012-03-19 22:56:35
|
On Sun, 2012-03-18 at 23:59 +0200, Andrew wrote: > 18.03.2012 19:44, davidMbrooke пишет: > > > > 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 > AFAIK there is no difference between '-pc-linux-uclibc' and > '-unknown-linux-uclibc' suffixes, and IMHO it'll be safe to use > i486-unknown-linux-uclibc arch. Thanks Andrew. I therefore propose to identify the different toolchains with "GNU_TARGET_NAME" strings like i486-unknown-linux-uclibc, instead of "ARCH" strings like i386. I will add a "-t toolchain" argument to buildtool.pl and default this to i486-unknown-linux-uclibc so as to preserve the current behaviour. I have these changes working in my development environment now (plus a few other changes to prepare for non-x86 platforms) but I want to review those again before adding to Git (hopefully tomorrow). david |
From: davidMbrooke <le...@da...> - 2012-03-20 20:58:09
|
On Mon, 2012-03-19 at 22:56 +0000, davidMbrooke wrote: > On Sun, 2012-03-18 at 23:59 +0200, Andrew wrote: > > 18.03.2012 19:44, davidMbrooke пишет: > > > > > > 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 > > AFAIK there is no difference between '-pc-linux-uclibc' and > > '-unknown-linux-uclibc' suffixes, and IMHO it'll be safe to use > > i486-unknown-linux-uclibc arch. > > Thanks Andrew. I therefore propose to identify the different toolchains > with "GNU_TARGET_NAME" strings like i486-unknown-linux-uclibc, instead > of "ARCH" strings like i386. > I will add a "-t toolchain" argument to buildtool.pl and default this to > i486-unknown-linux-uclibc so as to preserve the current behaviour. > > I have these changes working in my development environment now (plus a > few other changes to prepare for non-x86 platforms) but I want to review > those again before adding to Git (hopefully tomorrow). > > david OK, changes now pushed to the SourceForge Git. Hopefully I have preserved the existing behaviour by default but now buildtool.pl has a "-t toolchainname" argument and buildpacket.pl has a "--toolchain toolchainname" argument. Both default to the (new) "toolchain" setting in conf/buildtool.conf Since the name of the toolchain directory has changed (was i386, now i486-unknown-linux-uclibc) any 'next' developers will need to re-build their toolchain after they pull my latest changes. I am also in the process of drafting some notes on building for other platforms here: http://sourceforge.net/apps/mediawiki/leaf/index.php?title=Bering-uClibc_5.x_-_Developer_Guide_-_Adding_a_Hardware_Architecture_Variant david |
From: KP K. <ka...@us...> - 2012-03-21 19:49:11
|
Am 20.03.2012 21:57, schrieb davidMbrooke: > On Mon, 2012-03-19 at 22:56 +0000, davidMbrooke wrote: >> On Sun, 2012-03-18 at 23:59 +0200, Andrew wrote: >> > 18.03.2012 19:44, davidMbrooke пишет: >> > > >> > > 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 >> > AFAIK there is no difference between '-pc-linux-uclibc' and >> > '-unknown-linux-uclibc' suffixes, and IMHO it'll be safe to use >> > i486-unknown-linux-uclibc arch. >> >> Thanks Andrew. I therefore propose to identify the different toolchains >> with "GNU_TARGET_NAME" strings like i486-unknown-linux-uclibc, instead >> of "ARCH" strings like i386. >> I will add a "-t toolchain" argument to buildtool.pl and default this to >> i486-unknown-linux-uclibc so as to preserve the current behaviour. >> >> I have these changes working in my development environment now (plus a >> few other changes to prepare for non-x86 platforms) but I want to review >> those again before adding to Git (hopefully tomorrow). >> >> david > > OK, changes now pushed to the SourceForge Git. Hopefully I have > preserved the existing behaviour by default but now buildtool.pl has a > "-t toolchainname" argument and buildpacket.pl has a "--toolchain > toolchainname" argument. Both default to the (new) "toolchain" setting > in conf/buildtool.conf > > Since the name of the toolchain directory has changed (was i386, now > i486-unknown-linux-uclibc) any 'next' developers will need to re-build > their toolchain after they pull my latest changes. Good work! I've took the chance to rebuild with latest linux kernel 3.2.12 and (once again) without uClibc-pthread_initialize.patch. A first test on my router looks pretty well. buildall.sh shows only package with a pb - yate. Anyway I committed new linux kernel and refreshed uclibc buildtool setup to git. kp |
From: Yves B. <blu...@us...> - 2012-03-21 10:48:07
|
Le 20/03/2012 21:57, davidMbrooke a écrit : > On Mon, 2012-03-19 at 22:56 +0000, davidMbrooke wrote: >> On Sun, 2012-03-18 at 23:59 +0200, Andrew wrote: >>> 18.03.2012 19:44, davidMbrooke пишет: >>>> 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 >>> AFAIK there is no difference between '-pc-linux-uclibc' and >>> '-unknown-linux-uclibc' suffixes, and IMHO it'll be safe to use >>> i486-unknown-linux-uclibc arch. >> Thanks Andrew. I therefore propose to identify the different toolchains >> with "GNU_TARGET_NAME" strings like i486-unknown-linux-uclibc, instead >> of "ARCH" strings like i386. >> I will add a "-t toolchain" argument to buildtool.pl and default this to >> i486-unknown-linux-uclibc so as to preserve the current behaviour. >> >> I have these changes working in my development environment now (plus a >> few other changes to prepare for non-x86 platforms) but I want to review >> those again before adding to Git (hopefully tomorrow). >> >> david > OK, changes now pushed to the SourceForge Git. Hopefully I have > preserved the existing behaviour by default but now buildtool.pl has a > "-t toolchainname" argument and buildpacket.pl has a "--toolchain > toolchainname" argument. Both default to the (new) "toolchain" setting > in conf/buildtool.conf > > Since the name of the toolchain directory has changed (was i386, now > i486-unknown-linux-uclibc) any 'next' developers will need to re-build > their toolchain after they pull my latest changes. > > I am also in the process of drafting some notes on building for other > platforms here: > http://sourceforge.net/apps/mediawiki/leaf/index.php?title=Bering-uClibc_5.x_-_Developer_Guide_-_Adding_a_Hardware_Architecture_Variant > > david Great doc david. Toolchain built without errors on my fedora 15. One suggestion: it will be great to have a subdirectory in the /build/ directory with the name of the toolchain. For example: build/i486-unknown-linux-uclibc so we can build multiple versions of a package for different architecture. Yves |
From: Andrew <ni...@se...> - 2012-03-21 11:08:32
|
On 21/03/12 12:47, Yves Blusseau wrote: > Le 20/03/2012 21:57, davidMbrooke a écrit : >> On Mon, 2012-03-19 at 22:56 +0000, davidMbrooke wrote: >>> On Sun, 2012-03-18 at 23:59 +0200, Andrew wrote: >>>> 18.03.2012 19:44, davidMbrooke пишет: >>>>> 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 >>>> AFAIK there is no difference between '-pc-linux-uclibc' and >>>> '-unknown-linux-uclibc' suffixes, and IMHO it'll be safe to use >>>> i486-unknown-linux-uclibc arch. >>> Thanks Andrew. I therefore propose to identify the different toolchains >>> with "GNU_TARGET_NAME" strings like i486-unknown-linux-uclibc, instead >>> of "ARCH" strings like i386. >>> I will add a "-t toolchain" argument to buildtool.pl and default this to >>> i486-unknown-linux-uclibc so as to preserve the current behaviour. >>> >>> I have these changes working in my development environment now (plus a >>> few other changes to prepare for non-x86 platforms) but I want to review >>> those again before adding to Git (hopefully tomorrow). >>> >>> david >> OK, changes now pushed to the SourceForge Git. Hopefully I have >> preserved the existing behaviour by default but now buildtool.pl has a >> "-t toolchainname" argument and buildpacket.pl has a "--toolchain >> toolchainname" argument. Both default to the (new) "toolchain" setting >> in conf/buildtool.conf >> >> Since the name of the toolchain directory has changed (was i386, now >> i486-unknown-linux-uclibc) any 'next' developers will need to re-build >> their toolchain after they pull my latest changes. >> >> I am also in the process of drafting some notes on building for other >> platforms here: >> http://sourceforge.net/apps/mediawiki/leaf/index.php?title=Bering-uClibc_5.x_-_Developer_Guide_-_Adding_a_Hardware_Architecture_Variant >> >> david > Great doc david. > > Toolchain built without errors on my fedora 15. > > One suggestion: it will be great to have a subdirectory in the /build/ > directory with the name of the toolchain. > For example: build/i486-unknown-linux-uclibc so we can build multiple > versions of a package for different architecture. > > Yves > > Yes, and also it'll be good to have subdir in /source/ directory. |
From: Mike N. <mh...@us...> - 2012-03-21 19:50:55
|
On 03/20/2012 01:57 PM, davidMbrooke wrote: -snip- > I am also in the process of drafting some notes on building for other > platforms here: > http://sourceforge.net/apps/mediawiki/leaf/index.php?title=Bering-uClibc_5.x_-_Developer_Guide_-_Adding_a_Hardware_Architecture_Variant David, Great start on this document. Everyone, Anyone with cross-complie experience please review and comment on the document. Thanks. -- Mike Noyes http://sourceforge.net/users/mhnoyes https://profiles.google.com/mhnoyes |
From: davidMbrooke <le...@da...> - 2012-03-21 22:21:56
|
On Wed, 2012-03-21 at 13:08 +0200, Andrew wrote: > On 21/03/12 12:47, Yves Blusseau wrote: > > One suggestion: it will be great to have a subdirectory in the /build/ > > directory with the name of the toolchain. > > For example: build/i486-unknown-linux-uclibc so we can build multiple > > versions of a package for different architecture. > > > > Yves > > > Yes, and also it'll be good to have subdir in /source/ directory. You guys are never happy, are you? :-} I have now changed the buildtool scripts and config files so that: source/ -> source/i486-unknown-linux-uclibc/ build/ -> build/i486-unknown-linux-uclibc/ and also: conf/installed -> conf/i486-unknown-linux-uclibc/installed since we need to track what has been built on a per-toolchain basis. Seems to work OK for me from limited testing but I suspect some buildtool operations will not work. Please check and report any problems. By the way, I know that buildimage.pl is now broken because of these and my other changes. Maybe I can fix that tomorrow... david |
From: davidMbrooke <le...@da...> - 2012-03-22 20:36:57
|
On Wed, 2012-03-21 at 22:21 +0000, davidMbrooke wrote: > > By the way, I know that buildimage.pl is now broken because of these and > my other changes. Maybe I can fix that tomorrow... > > david buildimage.pl should now be fixed too - at least for i486 builds - and also tools/buildall.sh which wasn't looking in the right place for source/*/buildtool.cfg files. The default behaviour of all the build utilities should therefore be back to where it was before but now there's an option to specify a different toolchain in (conf/buildtool.cfg or on the command line) and the toolchain name is reflected in all the generated directories as a basis for adding further toolchains for other platforms I do seem to have re-introduced a number of build failures (mawk, linux-atm, dhcpd) which is down to a *second* i486-unknown-linux-uclibc level in the directory structures in some places (specifically for the include files, which are therefore not being found, hence the build failures). I'm hunting the cause of that right now. david |
From: davidMbrooke <le...@da...> - 2012-03-22 23:00:23
|
On Thu, 2012-03-22 at 20:36 +0000, davidMbrooke wrote: > > I do seem to have re-introduced a number of build failures (mawk, > linux-atm, dhcpd) which is down to a *second* i486-unknown-linux-uclibc > level in the directory structures in some places (specifically for the > include files, which are therefore not being found, hence the build > failures). I'm hunting the cause of that right now. > > david Struggling to spot what is wrong... Andrew: You are perhaps more familiar with toolchain/buildtool.mk Do the results of building the toolchain match what you expect? Seems like we have an extra GNU_TARGET_NAME level in some places... Thanks, david |
From: KP K. <ka...@us...> - 2012-03-23 18:02:35
|
Am 22.03.2012 21:36, schrieb davidMbrooke: > On Wed, 2012-03-21 at 22:21 +0000, davidMbrooke wrote: >> >> By the way, I know that buildimage.pl is now broken because of these and >> my other changes. Maybe I can fix that tomorrow... >> >> david > > buildimage.pl should now be fixed too - at least for i486 builds - and > also tools/buildall.sh which wasn't looking in the right place for > source/*/buildtool.cfg files. > > The default behaviour of all the build utilities should therefore be > back to where it was before but now there's an option to specify a > different toolchain in (conf/buildtool.cfg or on the command line) and > the toolchain name is reflected in all the generated directories as a > basis for adding further toolchains for other platforms > > I do seem to have re-introduced a number of build failures (mawk, > linux-atm, dhcpd) which is down to a *second* i486-unknown-linux-uclibc > level in the directory structures in some places (specifically for the > include files, which are therefore not being found, hence the build > failures). I'm hunting the cause of that right now. Hi David; just rebuilded. I don't see any errors... Haven't tested buildpackage yet. kp |
From: davidMbrooke <le...@da...> - 2012-03-23 20:49:46
|
On Fri, 2012-03-23 at 19:02 +0100, KP Kirchdoerfer wrote: > Am 22.03.2012 21:36, schrieb davidMbrooke: > > On Wed, 2012-03-21 at 22:21 +0000, davidMbrooke wrote: > > I do seem to have re-introduced a number of build failures (mawk, > > linux-atm, dhcpd) > > Hi David; > > just rebuilded. I don't see any errors... > > Haven't tested buildpackage yet. > > kp Hi kp, Thanks for checking. Are you building on 32-bit x86 by any chance, rather than 64-bit x86_64 like me? For mawk and linux-atm the problem seems to be that they are trying to run executables on the build host as part of the build process, but those executables are intended for the target host... A possible workaround is to run the executables manually, store the output in Git and insert the output into the source tree as part of "make source". That will only work if the output is platform independent though. I'm starting to look at dhcpd (again!) now. david |
From: KP K. <ka...@us...> - 2012-03-23 23:40:18
|
Am 23.03.2012 21:49, schrieb davidMbrooke: > On Fri, 2012-03-23 at 19:02 +0100, KP Kirchdoerfer wrote: >> Am 22.03.2012 21:36, schrieb davidMbrooke: >> > On Wed, 2012-03-21 at 22:21 +0000, davidMbrooke wrote: >> > I do seem to have re-introduced a number of build failures (mawk, >> > linux-atm, dhcpd) >> >> Hi David; >> >> just rebuilded. I don't see any errors... >> >> Haven't tested buildpackage yet. >> >> kp > > Hi kp, > > Thanks for checking. Are you building on 32-bit x86 by any chance, > rather than 64-bit x86_64 like me? Yes I'm still on 32-bit. kp |
From: davidMbrooke <le...@da...> - 2012-03-24 07:53:13
|
On Sat, 2012-03-24 at 00:40 +0100, KP Kirchdoerfer wrote: > > Yes I'm still on 32-bit. > > kp Hi kp, OK, so that explains why it works for you but not for me. I've realized that compiling for the build host rather than the target host is *exactly* what $(BUILD_CC) is for and I've had some success with mawk by editing the Makefile to use $(BUILD_CC) for the relevant step. Hopefully I can do the same for linux-atm and dhcpd. My current thinking is that the toolchain is working properly. Testing with a more "different" target (like ARM) will help prove that one way or the other. david |
From: davidMbrooke <le...@da...> - 2012-03-27 20:05:02
|
On Wed, 2012-03-21 at 12:50 -0700, Mike Noyes wrote: > On 03/20/2012 01:57 PM, davidMbrooke wrote: > -snip- > > I am also in the process of drafting some notes on building for other > > platforms here: > > http://sourceforge.net/apps/mediawiki/leaf/index.php?title=Bering-uClibc_5.x_-_Developer_Guide_-_Adding_a_Hardware_Architecture_Variant > > David, > Great start on this document. > > Everyone, > Anyone with cross-complie experience please review and comment on the > document. Thanks. Thanks Mike. I have now completed the document based on what was in my head. It now describes all the places where the build system has to be configured in order to add a custom toolchain (really only 3 places - some simple config settings in make/MasterInclude.mk, a custom patch for the Linux kernel .config and a custom uClibc .config). I have also started a Discussion page at the same location to track Q&A. david |
From: Yves B. <blu...@us...> - 2012-03-28 09:55:44
|
Le 27/03/2012 22:04, davidMbrooke a écrit : > Thanks Mike. I have now completed the document based on what was in my > head. It now describes all the places where the build system has to be > configured in order to add a custom toolchain (really only 3 places - > some simple config settings in make/MasterInclude.mk, a custom patch for > the Linux kernel .config and a custom uClibc .config). > > I have also started a Discussion page at the same location to track Q&A. > > david > Thanks david for the documentation. Just some questions: i have a soekris net6501 board (with an Atom E6xx series processor). If i take the "standard" configuration (|i486-unknown-linux-uclibc) buildtoo.pl will use the parameters defined in ||make/MasterInclude.mk: | ARCH:=i386 KARCHS:=i686 i486 geode KARCHS_PCIE:=i686 ARCH_CFLAGS=-march=i486 -mtune=pentiumpro I think it's not optimal for my board (i don't have to compile for i486 and mtune can be more specific). So my question: what is the best changes i need to do to have optimisation for my board ? I think i need a specific triplet name like atom-net6501-linux-uclibc ? with in|make/MasterInclude.mk:| |else ifeq ($(GNU_TARGET_NAME),atom-net6501-linux-uclibc) # Primary kernel architecture export ARCH:=x86_64 # Space-separated list of kernel sub-archs to generate export KARCHS:=net6501| export KARCHS_PCIE:=net6501 |# Arch-specific CFLAGS export ARCH_CFLAGS=-march=atom -mtune=atom is it right (like the |KARCHS_PCIE) |? This is just a use case to understand how we can change things for a proper toolchain. Regards, Yves || | |
From: Andrew <ni...@se...> - 2012-03-28 10:14:33
|
28.03.2012 12:55, Yves Blusseau написал: > Le 27/03/2012 22:04, davidMbrooke a écrit : >> Thanks Mike. I have now completed the document based on what was in my >> head. It now describes all the places where the build system has to be >> configured in order to add a custom toolchain (really only 3 places - >> some simple config settings in make/MasterInclude.mk, a custom patch for >> the Linux kernel .config and a custom uClibc .config). >> >> I have also started a Discussion page at the same location to track Q&A. >> >> david >> > Thanks david for the documentation. Just some questions: i have a > soekris net6501 board (with an Atom E6xx series processor). > If i take the "standard" configuration (|i486-unknown-linux-uclibc) > buildtoo.pl will use the parameters defined in ||make/MasterInclude.mk: > | > > ARCH:=i386 > KARCHS:=i686 i486 geode > KARCHS_PCIE:=i686 > ARCH_CFLAGS=-march=i486 -mtune=pentiumpro > > I think it's not optimal for my board (i don't have to compile for i486 and mtune can be more specific). > > So my question: what is the best changes i need to do to have optimisation for my board ? > I think i need a specific triplet name like atom-net6501-linux-uclibc ? > with in|make/MasterInclude.mk:| > > |else ifeq ($(GNU_TARGET_NAME),atom-net6501-linux-uclibc) > # Primary kernel architecture > export ARCH:=x86_64 > # Space-separated list of kernel sub-archs to generate > export KARCHS:=net6501| > export KARCHS_PCIE:=net6501 > |# Arch-specific CFLAGS > export ARCH_CFLAGS=-march=atom -mtune=atom > > is it right (like the |KARCHS_PCIE) |? > > This is just a use case to understand how we can change things for a > proper toolchain. > > Regards, > Yves > || > | ARCH_CFLAGS involves only userland libraries, kernel is compiled for selected arch - so you bother for 2-3% speedup of userland that is negligible. Tuning for specific arch instead of generic (pentium4 vs i686, atom vs x86_64, etc) will give just some % of speed-up. Also switching from i686 to x86_64 may cause performance drop (larger code will cause more frequent cache misses), and no performance boost at least on IPv4 (it operates with 32bit or less data). And second, for host names there are standard names, you can't defune your own arch - libtool will not know it, and you'll have errors on compilation. So if you want to speed-up your box - it'll be enough to make kernel optimized for your box, and use it with generic userland for your architecture. |
From: Yves B. <blu...@us...> - 2012-03-28 10:57:45
|
Le 28/03/2012 12:14, Andrew a écrit : > 28.03.2012 12:55, Yves Blusseau написал: >> Le 27/03/2012 22:04, davidMbrooke a écrit : >>> Thanks Mike. I have now completed the document based on what was in my >>> head. It now describes all the places where the build system has to be >>> configured in order to add a custom toolchain (really only 3 places - >>> some simple config settings in make/MasterInclude.mk, a custom patch for >>> the Linux kernel .config and a custom uClibc .config). >>> >>> I have also started a Discussion page at the same location to track Q&A. >>> >>> david >>> >> Thanks david for the documentation. Just some questions: i have a >> soekris net6501 board (with an Atom E6xx series processor). >> If i take the "standard" configuration (|i486-unknown-linux-uclibc) >> buildtoo.pl will use the parameters defined in ||make/MasterInclude.mk: >> | >> >> ARCH:=i386 >> KARCHS:=i686 i486 geode >> KARCHS_PCIE:=i686 >> ARCH_CFLAGS=-march=i486 -mtune=pentiumpro >> >> I think it's not optimal for my board (i don't have to compile for i486 and mtune can be more specific). >> >> So my question: what is the best changes i need to do to have optimisation for my board ? >> I think i need a specific triplet name like atom-net6501-linux-uclibc ? >> with in|make/MasterInclude.mk:| >> >> |else ifeq ($(GNU_TARGET_NAME),atom-net6501-linux-uclibc) >> # Primary kernel architecture >> export ARCH:=x86_64 >> # Space-separated list of kernel sub-archs to generate >> export KARCHS:=net6501| >> export KARCHS_PCIE:=net6501 >> |# Arch-specific CFLAGS >> export ARCH_CFLAGS=-march=atom -mtune=atom >> >> is it right (like the |KARCHS_PCIE) |? >> >> This is just a use case to understand how we can change things for a >> proper toolchain. >> >> Regards, >> Yves >> || >> | > ARCH_CFLAGS involves only userland libraries, kernel is compiled for > selected arch - so you bother for 2-3% speedup of userland that is > negligible. > Tuning for specific arch instead of generic (pentium4 vs i686, atom vs > x86_64, etc) will give just some % of speed-up. Also switching from i686 > to x86_64 may cause performance drop (larger code will cause more > frequent cache misses), and no performance boost at least on IPv4 (it > operates with 32bit or less data). Thanks andrew for the informations. > > And second, for host names there are standard names, you can't defune > your own arch - libtool will not know it, and you'll have errors on > compilation. You speak about the net6501 for the KARCHS variable or the GNU_TARGET_NAME ? > So if you want to speed-up your box - it'll be enough to make kernel > optimized for your box, and use it with generic userland for your > architecture. So the best is to OVERRIDE the i486-unknown-linux-uclibc triplet in make/MasterInclude.mk with something like: ifeq ($(GNU_TARGET_NAME),i486-unknown-linux-uclibc) # Primary kernel architecture export ARCH:=i386 # Space-separated list of kernel sub-archs to generate export KARCHS:=net6501 # Available kernel archs with pci-express support export KARCHS_PCIE:=i686 # Arch-specific CFLAGS export ARCH_CFLAGS=-march=i486 -mtune=pentiumpro and create a dedicated kernel config file Bering-3.2.13.config-net6501.patch ? Yves |
From: Andrew <ni...@se...> - 2012-03-28 11:07:05
|
28.03.2012 13:57, Yves Blusseau написал: > Le 28/03/2012 12:14, Andrew a écrit : >> 28.03.2012 12:55, Yves Blusseau написал: >>> Le 27/03/2012 22:04, davidMbrooke a écrit : >>>> Thanks Mike. I have now completed the document based on what was in my >>>> head. It now describes all the places where the build system has to be >>>> configured in order to add a custom toolchain (really only 3 places - >>>> some simple config settings in make/MasterInclude.mk, a custom patch for >>>> the Linux kernel .config and a custom uClibc .config). >>>> >>>> I have also started a Discussion page at the same location to track Q&A. >>>> >>>> david >>>> >>> Thanks david for the documentation. Just some questions: i have a >>> soekris net6501 board (with an Atom E6xx series processor). >>> If i take the "standard" configuration (|i486-unknown-linux-uclibc) >>> buildtoo.pl will use the parameters defined in ||make/MasterInclude.mk: >>> | >>> >>> ARCH:=i386 >>> KARCHS:=i686 i486 geode >>> KARCHS_PCIE:=i686 >>> ARCH_CFLAGS=-march=i486 -mtune=pentiumpro >>> >>> I think it's not optimal for my board (i don't have to compile for i486 and mtune can be more specific). >>> >>> So my question: what is the best changes i need to do to have optimisation for my board ? >>> I think i need a specific triplet name like atom-net6501-linux-uclibc ? >>> with in|make/MasterInclude.mk:| >>> >>> |else ifeq ($(GNU_TARGET_NAME),atom-net6501-linux-uclibc) >>> # Primary kernel architecture >>> export ARCH:=x86_64 >>> # Space-separated list of kernel sub-archs to generate >>> export KARCHS:=net6501| >>> export KARCHS_PCIE:=net6501 >>> |# Arch-specific CFLAGS >>> export ARCH_CFLAGS=-march=atom -mtune=atom >>> >>> is it right (like the |KARCHS_PCIE) |? >>> >>> This is just a use case to understand how we can change things for a >>> proper toolchain. >>> >>> Regards, >>> Yves >>> || >>> | >> ARCH_CFLAGS involves only userland libraries, kernel is compiled for >> selected arch - so you bother for 2-3% speedup of userland that is >> negligible. >> Tuning for specific arch instead of generic (pentium4 vs i686, atom vs >> x86_64, etc) will give just some % of speed-up. Also switching from i686 >> to x86_64 may cause performance drop (larger code will cause more >> frequent cache misses), and no performance boost at least on IPv4 (it >> operates with 32bit or less data). > Thanks andrew for the informations. >> And second, for host names there are standard names, you can't defune >> your own arch - libtool will not know it, and you'll have errors on >> compilation. > You speak about the net6501 for the KARCHS variable or the > GNU_TARGET_NAME ? GNU_TARGET_NAME >> So if you want to speed-up your box - it'll be enough to make kernel >> optimized for your box, and use it with generic userland for your >> architecture. > So the best is to OVERRIDE the i486-unknown-linux-uclibc triplet in > make/MasterInclude.mk with something like: > > ifeq ($(GNU_TARGET_NAME),i486-unknown-linux-uclibc) > # Primary kernel architecture > export ARCH:=i386 > # Space-separated list of kernel sub-archs to generate > export KARCHS:=net6501 > # Available kernel archs with pci-express support > export KARCHS_PCIE:=i686 > # Arch-specific CFLAGS > export ARCH_CFLAGS=-march=i486 -mtune=pentiumpro > > and create a dedicated kernel config file > Bering-3.2.13.config-net6501.patch ? > > Yves > Not replace, just add new KARCH net6501 and add it in KARCHS_PCIE if you use pci-express devices. |
From: Yves B. <blu...@us...> - 2012-03-28 11:02:53
|
Le 21/03/2012 23:21, davidMbrooke a écrit : > On Wed, 2012-03-21 at 13:08 +0200, Andrew wrote: >> On 21/03/12 12:47, Yves Blusseau wrote: >>> One suggestion: it will be great to have a subdirectory in the /build/ >>> directory with the name of the toolchain. >>> For example: build/i486-unknown-linux-uclibc so we can build multiple >>> versions of a package for different architecture. >>> >>> Yves >>> >> Yes, and also it'll be good to have subdir in /source/ directory. > You guys are never happy, are you? :-} > > I have now changed the buildtool scripts and config files so that: > source/ -> source/i486-unknown-linux-uclibc/ > build/ -> build/i486-unknown-linux-uclibc/ > > and also: > conf/installed -> conf/i486-unknown-linux-uclibc/installed > since we need to track what has been built on a per-toolchain basis. Hi david, i know i never happy perhaps we can change Logfile = log/buildtoollog to Logfile = log/$GNU_TARGET_NAME/buildtoollog in conf/buildtool.conf |
From: davidMbrooke <le...@da...> - 2012-03-29 16:33:28
|
On Wed, 2012-03-28 at 13:02 +0200, Yves Blusseau wrote: > Hi david, i know i never happy > > perhaps we can change > > Logfile = log/buildtoollog > to > Logfile = log/$GNU_TARGET_NAME/buildtoollog > > in conf/buildtool.conf Hi Yves, I know you are right... I did consider making that change initially but it is slightly complex because buildtool.pl currently writes to the logfile *before* picking up the value for "toolchainname", so more of a change to the structure is required. I will look at this at the weekend. david |
From: Andrew <ni...@se...> - 2012-03-30 08:46:42
|
29.03.2012 19:33, davidMbrooke написал: > On Wed, 2012-03-28 at 13:02 +0200, Yves Blusseau wrote: >> Hi david, i know i never happy >> >> perhaps we can change >> >> Logfile = log/buildtoollog >> to >> Logfile = log/$GNU_TARGET_NAME/buildtoollog >> >> in conf/buildtool.conf > Hi Yves, > > I know you are right... I did consider making that change initially but > it is slightly complex because buildtool.pl currently writes to the > logfile *before* picking up the value for "toolchainname", so more of a > change to the structure is required. I will look at this at the weekend. > > david > I think that it isn't too important change. In any case, log is just for debugging troubles, and trouble will appear at the end of log :) And no matters how much packages are built before. I can imagine only one case in which it'll be good to have separate logs - parallel building for different archs, but it's not so important thing IMHO. |
From: Andrew <ni...@se...> - 2012-03-30 19:25:30
|
Hi all. Today I realized my idea of automation of package definition for initrd and moddb for each arch. It looks for me tiny and clear for understanding/modifying. Now there are template file with ##ARCH## tag and other files except kernel modules, and list of regexps for module names that are required for that package. It seems that nothing was forgotten in that operation - just removed some rarely-used modules; and some modules that are prerequisites for currently present in moddb were added in that way, + added some iptables-related and IPVS modules. So it waits testing, and now it seems that all environment is prepared for experiments in cross-compilation. |
From: KP K. <ka...@us...> - 2012-04-02 16:56:44
|
Am 30.03.2012 21:25, schrieb Andrew: > Hi all. > Today I realized my idea of automation of package definition for initrd > and moddb for each arch. It looks for me tiny and clear for > understanding/modifying. > Now there are template file with ##ARCH## tag and other files except > kernel modules, and list of regexps for module names that are required > for that package. > It seems that nothing was forgotten in that operation - just removed > some rarely-used modules; and some modules that are prerequisites for > currently present in moddb were added in that way, + added some > iptables-related and IPVS modules. > So it waits testing, and now it seems that all environment is prepared > for experiments in cross-compilation. Hi Andrew; pls look into my previous mail, how much I enjoy the/your work for cross-compiling. While I'm convinced that your approach works and is tiny, I'm not shure if it's "understandable". I looked a long time in to your changes and my impression is that you've "over-simplified" it. The logic to build the files for buildpacket.pl has been put into buildtool.mk, the file to declare the modules is really simple. Anyway it breaks the "rules" how to define the filelist for packages. So it's different compared to any other package. While the current approach is "stupid", it just works and until today it's always the same for every package. I'm afraid that putting the logic into buildtool.mk , and to make a difference in package definitions requires more documentation, raises questions and is in fact not as easy to understand as we like. If it's really necessary for cross-compiling I'll swallow it, if not I'd like to go with the common approach, just to keep it as simple as possible over the whole buildtool setup. opinions? kp |