Kernel Cross Compiling [update]

Kernel Cross Compiling [update]

[Herbert Poetzl]

Hi Folks!

Here is an update to the Kernel Cross Compiling thread 
I started ten days ago ...

1) CROSS COMPILER / TOOLCHAIN

   there are different solutions for the toolchain issue:
   
     - Dan Kegel's Crosstool [1]
     - PTXdist [2]
     - my simplified approach [3]

   in one mail [Ref-A], Jim Wilson mentioned that using the 
   'inhibit_libc' trick will break the gcc in a subtly way, 
   so I decided to verify the fitness of the compiled gcc.
   
   because 'normal' checks won't work without the glibc and
   the includes, I decided to take the following approach:
     
     - build gcc 3.3.2 with Dan's crosstool, and with my 
       simplified approach.
       
     - select all tests from the test suite which contain
       tests relevant for the kernel (no floats, no (g)libc
       includes)
     
     - compile each C source into Assembler code (gcc -O2 -S)
       with both compilers (crosstool gcc version and mine)
     
     - compare the resulting Assembler code and check for
       differences
     
   the GCC testsuite contains 2854 files in the relevant 
   subdirs consistency.vlad, gcc.c-torture, gcc.dg, and
   gcc.misc-tests.
    
   after removing the non relevant tests (file matching 
   egrep '#include|float|double') 1799 C files remain.
     
   the result of the tests and comparison[4] shows that
   both compilers produce the same code, except for one
   little difference[5], which I'm unable to explain ...  

   my conclusion so far is that my approach should be
   sufficient for Kernel Cross Compiling.


2) KERNEL CROSS COMPILING

   			   linux-2.6.3-rc3     linux-2.6.3
   			   config  build       config  build

   alpha/alpha: 	   OK	   OK	       OK      OK
   arm/arm:		   FAILED  FAILED      FAILED  FAILED
   cris/cris:		   FAILED  FAILED      FAILED  FAILED
   hppa/parisc: 	   OK	   FAILED      OK      FAILED
   hppa64/parisc:	   OK	   FAILED      OK      FAILED
   i386/i386:		   OK	   OK	       OK      OK
   ia64/ia64:		   OK	   OK	       OK      OK
   m68k/m68k:		   OK	   FAILED      OK      FAILED
   mips/mips:		   OK	   FAILED      OK      FAILED
   mips64/mips: 	   OK	   FAILED      OK      FAILED
   ppc/ppc:		   OK	   FAILED      OK      FAILED
   ppc64/ppc64: 	   OK	   OK	       OK      OK
   s390/s390:		   OK	   FAILED      OK      FAILED
   sh/sh:		   OK	   FAILED      OK      FAILED
   sh64/sh:		   OK	   FAILED      OK      FAILED
   sparc/sparc: 	   OK	   FAILED      OK      FAILED
   sparc64/sparc64:	   OK	   OK	       OK      OK
   v850/v850:		   FAILED  FAILED      FAILED  FAILED
   x86_64/x86_64:	   OK	   OK	       OK      OK

   
   interesting is that some architectures (arm, chris, v850)
   do not even have an appropriate default config, where 
   others seem to require different? binutils (sh and sh64)
   but most other issues seem to be inconsistent configs or
   broken headers/code (details [6])... 
   
   mips/mips64 seems to break because of an cpu= option 
   which was depreciated in gcc some time ago, so they might
   build again if those changes are merged back into mainline
   
   hppa/hppa64 seems to require heavy patches to make them
   compile, which might be too intrusive to get into mainline
   very soon.

   				   linux-2.4.25
   			   config  dep     kernel  modules

   alpha/alpha: 	   OK	   OK	   OK	   OK
   arm/arm:		   OK	   OK	   FAILED  FAILED
   cris/cris:		   OK	   FAILED  FAILED  FAILED
   hppa/parisc: 	   OK	   OK	   FAILED  FAILED
   hppa64/parisc:	   OK	   OK	   FAILED  FAILED
   i386/i386:		   OK	   OK	   OK	   OK
   ia64/ia64:		   OK	   OK	   FAILED  FAILED
   m68k/m68k:		   OK	   OK	   OK	   OK
   mips/mips:		   OK	   OK	   FAILED  FAILED
   mips64/mips64:	   OK	   OK	   FAILED  FAILED
   ppc/ppc:		   OK	   OK	   OK	   OK
   ppc64/ppc64: 	   OK	   FAILED  FAILED  OK
   s390/s390:		   OK	   OK	   OK	   OK
   sh/sh:		   OK	   OK	   FAILED  FAILED
   sh64/sh64:		   OK	   OK	   FAILED  FAILED
   sparc/sparc: 	   OK	   OK	   FAILED  OK
   sparc64/sparc64:	   OK	   OK	   OK	   OK
   v850/v850:		   FAILED  FAILED  FAILED  FAILED
   x86_64/x86_64:	   OK	   OK	   OK	   OK


   the logs[7] for the 2.4.25 kernel build suggest similar
   reasons for similar architectures (compared to 2.6.3)

3) CONCLUSIONS

   it seems that the fast/easy way to build a cross gcc
   compiler (at least on x86 ;) is sufficient for kernel
   cross compile tests. 

   6/7 out of 19 'supported' architectures are currently 
   building with the kernel default configuration, when 
   cross compiled in an x86 host (about a third).

   
best,
Herbert



[1]  http://kegel.com/crosstool
[2]  http://www.pengutronix.de/software/ptxdist_en.html
[3]  http://vserver.13thfloor.at/Stuff/Cross/howto.info
[4]  http://vserver.13thfloor.at/Stuff/Cross/Comparison
[5]  http://vserver.13thfloor.at/Stuff/Cross/Comparison/TEST-alpha.diff
[6]  http://vserver.13thfloor.at/Stuff/Cross/LOGS-2.6.3
[7]  http://vserver.13thfloor.at/Stuff/Cross/LOGS-2.4.25

[Ref-A]

On Mon, Feb 16, 2004 at 02:50:41PM -0800, Jim Wilson wrote:
> I recommend Dan Kegel's page for anyone trying to build a cross compiler
> to linux.  See
> 		  http://kegel.com/crosstool
> This isn't very hard to follow, and it gives you a properly configured
> and built gcc/glibc for the target.
>
> I don't recommend the inhibit_libc trick for building linux crosses.
> It may work well enough for kernel builds, but it will give you a subtly
> broken gcc, and that may lead to confusion later.

Re: Kernel Cross Compiling [update]

[Dan Kegel]

Herbert Poetzl wrote:
>    the GCC testsuite contains 2854 files in the relevant 
>    subdirs consistency.vlad, gcc.c-torture, gcc.dg, and
>    gcc.misc-tests.
>     
>    after removing the non relevant tests (file matching 
>    egrep '#include|float|double') 1799 C files remain.
>      
>    the result of the tests and comparison[4] shows that
>    both compilers produce the same code, except for one
>    little difference[5], which I'm unable to explain ...  
 > [5]  http://vserver.13thfloor.at/Stuff/Cross/Comparison/TEST-alpha.diff
 > ...

>    my conclusion so far is that my approach should be
>    sufficient for Kernel Cross Compiling.

Perhaps, but it's harder to repeat than using my crosstool script;
you said you had to munge a bunch of header files, but with
crosstool no special munging is required.  AFAIR you haven't
posted your header-munging procedure.

It's vaguely possible that your header munging was wrong, which
caused that one diff on alpha.

Say, could you compare compiling the kernel with the two
toolchains, and see if there are any differences?
- Dan

-- 
US citizens: if you're considering voting for Bush, look at these first:
http://www.misleader.org/
http://www.cbc.ca/news/background/arar/
http://www.house.gov/reform/min/politicsandscience/

Re: Kernel Cross Compiling [update]

[Herbert Poetzl]

On Sat, Feb 21, 2004 at 10:02:29PM -0800, Dan Kegel wrote:
> Herbert Poetzl wrote:
> >   the GCC testsuite contains 2854 files in the relevant 
> >   subdirs consistency.vlad, gcc.c-torture, gcc.dg, and
> >   gcc.misc-tests.
> >    
> >   after removing the non relevant tests (file matching 
> >   egrep '#include|float|double') 1799 C files remain.
> >     
> >   the result of the tests and comparison[4] shows that
> >   both compilers produce the same code, except for one
> >   little difference[5], which I'm unable to explain ...  
> > [5]  http://vserver.13thfloor.at/Stuff/Cross/Comparison/TEST-alpha.diff
> > ...
> 
> >   my conclusion so far is that my approach should be
> >   sufficient for Kernel Cross Compiling.
> 
> Perhaps, but it's harder to repeat than using my crosstool script;
> you said you had to munge a bunch of header files, but with
> crosstool no special munging is required.  AFAIR you haven't
> posted your header-munging procedure.

you probably 'only' missed it, because I provide
(and did provide) ALL the required patches since
the first posting ...

http://vserver.13thfloor.at/Stuff/Cross/

the header changes are 'minimal' and labeled
gcc-3.3.2-cross-*-fix.diff.bz2

> It's vaguely possible that your header munging was wrong, which
> caused that one diff on alpha.

might be, if you know what's wrong, please let me 
know ... the differences for alpha can be found at

http://vserver.13thfloor.at/Stuff/Cross/gcc-3.3.2-cross-alpha-fix.diff.bz2

> Say, could you compare compiling the kernel with the two
> toolchains, and see if there are any differences?

hmm, yes, problem is, after 'downgrading' my binutils
to 2.14 (from 2.14.90.0.8) both toolchains (yours and
mine) fail to compile the alpha 2.6.3 kernel with

make: *** [.tmp_vmlinux1] Error 139

(with 2.14.90.0.8 mine seems to work, haven't tried to
update yours)

but I figured that comparing the .o files, especially
the built-in.o for each directory, would be a good
alternative ... to do that, I did the folowing:

 - find all built-in object files (84)
 - dump the code with 'objdump -d' 
 - compare the resulting code with diff

besides the expected difference caused by the path

-linux-2.6.3-bertl/drivers/built-in.o:     file format elf64-alpha
+linux-2.6.3-dan/drivers/built-in.o:     file format elf64-alpha
 
the only 'real' difference is this, which looks to
me equivalent, but I don't know what causes this
difference ...
 
@@ -29385,10 +29385,10 @@ Disassembly of section .text:
    1bf34:      00 00 fe 2f     unop    
    1bf38:      1f 04 ff 47     nop     
    1bf3c:      00 00 fe 2f     unop    
-   1bf40:      0b 14 a4 45     or      s4,0x20,s2
-   1bf44:      20 00 8d 21     lda     s3,32(s4)
+   1bf40:      0c 14 a4 45     or      s4,0x20,s3
+   1bf44:      20 00 6d 21     lda     s2,32(s4)
    1bf48:      58 00 28 a4     ldq     t0,88(t7)
-   1bf4c:      02 04 6c 45     or      s2,s3,t1
+   1bf4c:      02 04 8b 45     or      s3,s2,t1
    1bf50:      01 00 22 44     and     t0,t1,t0
    1bf54:      74 fd 3f f4     bne     t0,1b528 <vt_ioctl+0xe88>
    1bf58:      40 00 de 20     lda     t5,64(sp)
@@ -29412,7 +29412,7 @@ Disassembly of section .text:
    1bfa0:      00 00 fe 2f     unop    
    1bfa4:      0a fa 1f f4     bne     v0,1a7d0 <vt_ioctl+0x130>
    1bfa8:      58 00 28 a4     ldq     t0,88(t7)
-   1bfac:      02 04 6c 45     or      s2,s3,t1
+   1bfac:      02 04 8b 45     or      s3,s2,t1
    1bfb0:      01 00 22 44     and     t0,t1,t0
    1bfb4:      5c fd 3f f4     bne     t0,1b528 <vt_ioctl+0xe88>
    1bfb8:      06 04 ed 47     mov     s4,t5


best,
Herbert

> - Dan
> 
> -- 
> US citizens: if you're considering voting for Bush, look at these first:
> http://www.misleader.org/
> http://www.cbc.ca/news/background/arar/
> http://www.house.gov/reform/min/politicsandscience/

Re: Kernel Cross Compiling [update]

[Geert Uytterhoeven]

On Sun, 22 Feb 2004, Herbert Poetzl wrote:
> 2) KERNEL CROSS COMPILING
>
>    			   linux-2.6.3-rc3     linux-2.6.3
>    			   config  build       config  build
>
>    m68k/m68k:		   OK	   FAILED      OK      FAILED

Can you tell me where it fails? I guess the dmapool code, since no one has
merged the patch to fix that issue on m68k yet (speaking about stable kernel
series that break architectures in a release candidate with a known fix in
time...)

>    interesting is that some architectures (arm, chris, v850)
>    do not even have an appropriate default config, where
>    others seem to require different? binutils (sh and sh64)
>    but most other issues seem to be inconsistent configs or
>    broken headers/code (details [6])...

I have to admit I never bothered to update defconfigs for m68k.

If you want the ones I use for cross-compile testing, feel free to ask...

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: Kernel Cross Compiling [update]

[Russell King]

On Sun, Feb 22, 2004 at 04:53:50AM +0100, Herbert Poetzl wrote:
>    interesting is that some architectures (arm, chris, v850)
>    do not even have an appropriate default config

For some (eg ARM) one single default config makes zero sense.  I've
been debating about removing arch/arm/defconfig for this reason; we
have a whole host of machine default configurations in arch/arm/config
to serve this purpose.

>    				   linux-2.4.25
>    			   config  dep     kernel  modules
> 
>    alpha/alpha: 	   OK	   OK	   OK	   OK
>    arm/arm:		   OK	   OK	   FAILED  FAILED

ARM is not expected to build in 2.4 kernels, and probably never will.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core

Re: Kernel Cross Compiling [update]

[Herbert Poetzl]

On Sun, Feb 22, 2004 at 09:07:11AM +0000, Russell King wrote:
> On Sun, Feb 22, 2004 at 04:53:50AM +0100, Herbert Poetzl wrote:
> >    interesting is that some architectures (arm, chris, v850)
> >    do not even have an appropriate default config
> 
> For some (eg ARM) one single default config makes zero sense.  I've
> been debating about removing arch/arm/defconfig for this reason; we
> have a whole host of machine default configurations in arch/arm/config
> to serve this purpose.

ah, okay, so could you 'suggest' or even 'provide' a config
which is somewhat 'representative' for the arm kernel
architecture, so that (mostly) platform independant patches
could be tested on this arch?

> >    				   linux-2.4.25
> >    			   config  dep     kernel  modules
> > 
> >    alpha/alpha: 	   OK	   OK	   OK	   OK
> >    arm/arm:		   OK	   OK	   FAILED  FAILED
> 
> ARM is not expected to build in 2.4 kernels, and probably never will.

okay, so this is a dead end for 2.4, right?

TIA,
Herbert

> -- 
> Russell King
>  Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
>  maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
>                  2.6 Serial core
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: Kernel Cross Compiling [update]

[Dr. David Alan Gilbert]

* Herbert Poetzl (herbert@13thfloor.at) wrote:
> 
> Hi Folks!
> 
> Here is an update to the Kernel Cross Compiling thread 
> I started ten days ago ...

Hi,
   Quite a while ago I tried going through a similar
process.   I found at the time the debian toolchain-source
package helped in this process.

There is however one thing you seem to have missed - you
tend to need subtely different versions of gcc and binutils
for each combination.

It certainly used to be the case that every architectures
kernel used to have different known issues in both gcc
and binutils; and there was a fair amount of 'oh don't
use that version, it produces broken kernels' with
different answers for each architecture.

At one time I tried to make a summary page showing where
the kernel source and tools are for each architecture;
but I never kept it upto date.
(http://www.treblig.org/Linux_kernel_source_finder.html)

Dave

 -----Open up your eyes, open up your mind, open up your code -------   
/ Dr. David Alan Gilbert    | Running GNU/Linux on Alpha,68K| Happy  \ 
\ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex /
 \ _________________________|_____ http://www.treblig.org   |_______/

Re: Kernel Cross Compiling [update]

[Herbert Poetzl]

On Sun, Feb 22, 2004 at 12:45:41PM +0000, Dr. David Alan Gilbert wrote:
> * Herbert Poetzl (herbert@13thfloor.at) wrote:
> > 
> > Hi Folks!
> > 
> > Here is an update to the Kernel Cross Compiling thread 
> > I started ten days ago ...
> 
> Hi,
>    Quite a while ago I tried going through a similar
> process.   I found at the time the debian toolchain-source
> package helped in this process.
> 
> There is however one thing you seem to have missed - you
> tend to need subtely different versions of gcc and binutils
> for each combination.

not missed, but ignored on purpose ;)

> It certainly used to be the case that every architectures
> kernel used to have different known issues in both gcc
> and binutils; and there was a fair amount of 'oh don't
> use that version, it produces broken kernels' with
> different answers for each architecture.

hmm, that sounds too familiar, and I already prepared
to have different binutils, different gcc and some special
conditions for each build ... but I'm trying to minimize
the differences where possible ...

> At one time I tried to make a summary page showing where
> the kernel source and tools are for each architecture;
> but I never kept it upto date.
> (http://www.treblig.org/Linux_kernel_source_finder.html)

this looks quite useful, maybe you have some 'updated'
info, which could be of value to this efford, if so,
please let me know ...

anyway, thanks for the url, I was planning to do something
similar when I have all the details ...

best,
Herbert

> Dave
> 
>  -----Open up your eyes, open up your mind, open up your code -------   
> / Dr. David Alan Gilbert    | Running GNU/Linux on Alpha,68K| Happy  \ 
> \ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex /
>  \ _________________________|_____ http://www.treblig.org   |_______/
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: Kernel Cross Compiling [update]

[Paul Mundt]

[-- Attachment #1: Type: text/plain, Size: 1099 bytes --]

On Sun, Feb 22, 2004 at 04:53:50AM +0100, Herbert Poetzl wrote:
>    			   linux-2.6.3-rc3     linux-2.6.3
>    			   config  build       config  build
> 
>    sh/sh:		   OK	   FAILED      OK      FAILED
>    sh64/sh:		   OK	   FAILED      OK      FAILED

sh64 doesn't exist in 2.6 yet, attempting to build a kernel for it is futile.


>    others seem to require different? binutils (sh and sh64)
>    
sh and sh64 require completely different toolchains. They're very different
platforms, and have very little in common.

>    				   linux-2.4.25
>    			   config  dep     kernel  modules
> 
>    sh/sh:		   OK	   OK	   FAILED  FAILED

These are due to erroring on .rept usage for filling in the sys_call_table in
arch/sh/kernel/entry.S, in 2.6 we've already cleaned this up in the LinuxSH
tree by just dropping it and padding out for NR_syscalls, I suppose something
similar will have to be done in the 2.4 case..

>    sh64/sh64:		   OK	   OK	   FAILED  FAILED
> 
The sh64 build errors according to logs[7] are issues with your toolchain,
binutils in particular.


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Kernel Cross Compiling [update]

[Herbert Poetzl]

On Sun, Feb 22, 2004 at 10:52:09AM -0500, Paul Mundt wrote:
> On Sun, Feb 22, 2004 at 04:53:50AM +0100, Herbert Poetzl wrote:
> >    			   linux-2.6.3-rc3     linux-2.6.3
> >    			   config  build       config  build
> > 
> >    sh/sh:		   OK	   FAILED      OK      FAILED
> >    sh64/sh:		   OK	   FAILED      OK      FAILED
> 
> sh64 doesn't exist in 2.6 yet, attempting to build a kernel 
> for it is futile.

hmm, I guess that explains the sh64/sh build failure ... ;)

but why does the sh/sh case fail?

> >    others seem to require different? binutils (sh and sh64)
> >    
> sh and sh64 require completely different toolchains. 
> They're very different platforms, and have very little in common.

okay, binutils and gcc seem to 'know' sh and sh64 as 
architectures, (in my case binutils 2.14.90.0.8, and 
gcc 3.3.2, w/o any patches), what binutils/gcc would
you suggest for building sh or sh64?

> >    				   linux-2.4.25
> >    			   config  dep     kernel  modules
> > 
> >    sh/sh:		   OK	   OK	   FAILED  FAILED
> 
> These are due to erroring on .rept usage for filling in the 
> sys_call_table in arch/sh/kernel/entry.S, in 2.6 we've already 
> cleaned this up in the LinuxSH tree by just dropping it and 
> padding out for NR_syscalls, I suppose something similar will 
> have to be done in the 2.4 case..
> 
> >    sh64/sh64:		   OK	   OK	   FAILED  FAILED
> > 
> The sh64 build errors according to logs[7] are issues with your 
> toolchain, binutils in particular.

is there a toolchain/binutils which 'know' and 'support'
the '-isa=sh64' option? maybe it was depreciated?

gcc -isa=sh64 x.c
cc1: error: unrecognized option `-isa=sh64'

thanks for your input, I honestly appreciate it,

TIA,
Herbert

Re: Kernel Cross Compiling [update]

[Paul Mundt]

[-- Attachment #1: Type: text/plain, Size: 1296 bytes --]

On Sun, Feb 22, 2004 at 06:07:20PM +0100, Herbert Poetzl wrote:
> but why does the sh/sh case fail?
> 
The sh/sh case failed due to the .rept usage. I'm not entirely sure when
this started to pop up, but it does work again in binutils CVS (or at least
it did the last time I checked it out). For the time being, I've just gotten
rid of it entirely and just padded out with sys_ni_syscall. (Look at your
error log for the exact line).

> okay, binutils and gcc seem to 'know' sh and sh64 as 
> architectures, (in my case binutils 2.14.90.0.8, and 
> gcc 3.3.2, w/o any patches), what binutils/gcc would
> you suggest for building sh or sh64?
> 
A lot of that depends on what you're trying to build for. The sh defconfig
is for SH-3, in which case the default gcc and binutils should work just
fine. For SH-2 and SH-4, there's patch work that needs to be done both
for gcc and binutils.

> is there a toolchain/binutils which 'know' and 'support'
> the '-isa=sh64' option? maybe it was depreciated?
> 
I don't know of one out in the wild. SuperH has their own toolchains that
support this, and is what I currently use. I'm not sure what the status of
their patches are in relation to getting merged into current gcc/binutils.
Richard (CC'ed) might know though, Richard?


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Kernel Cross Compiling [update]

[Richard Curnow]

* Paul Mundt <lethal@linux-sh.org> [2004-02-23]:
> > is there a toolchain/binutils which 'know' and 'support'
> > the '-isa=sh64' option? maybe it was depreciated?
> > 
> I don't know of one out in the wild. SuperH has their own toolchains that
> support this, and is what I currently use. I'm not sure what the status of
> their patches are in relation to getting merged into current gcc/binutils.
> Richard (CC'ed) might know though, Richard?

The last public release we made of the SH-5 tools is available at

    ftp://ftp.uk.superh.com/pub/SuperH-GNU/Barcelona-20030414

This URL provides further information:

    http://sourceforge.net/mailarchive/forum.php?thread_id=1984379&forum_id=9482

The SH-5 tools we're currently using in-house are a few months more
advanced than those.  (They date from about August 2003.)  We'd be happy
to package this version up and make it available if people express
interest in this.

BTW, if anyone who's using the 2003_04_14 release has found any
problems, please do let me know and I'll pass the information on to the
toolchain guys.

-- 
Richard \\\ SH-4/SH-5 Core & Debug Architect
Curnow  \\\         SuperH (UK) Ltd, Bristol

Re: Kernel Cross Compiling [update]

[Herbert Poetzl]

On Mon, Feb 23, 2004 at 01:28:19PM +0000, Richard Curnow wrote:
> * Paul Mundt <lethal@linux-sh.org> [2004-02-23]:
> > > is there a toolchain/binutils which 'know' and 'support'
> > > the '-isa=sh64' option? maybe it was depreciated?
> > > 
> > I don't know of one out in the wild. SuperH has their own toolchains that
> > support this, and is what I currently use. I'm not sure what the status of
> > their patches are in relation to getting merged into current gcc/binutils.
> > Richard (CC'ed) might know though, Richard?
> 
> The last public release we made of the SH-5 tools is available at
> 
>     ftp://ftp.uk.superh.com/pub/SuperH-GNU/Barcelona-20030414

how are they related to the 'mainline' toolchain?

i.e. is this something completely separate, or do
you follow the binutils/gcc updates from time to time?

what would be the binutils/gcc version which is
'closest' to 'your' toolchain? wouldn't it make
sense to get those changes back into the mainline?

> This URL provides further information:
> 
>     http://sourceforge.net/mailarchive/forum.php?thread_id=1984379&forum_id=9482
> 
> The SH-5 tools we're currently using in-house are a few months more
> advanced than those.  (They date from about August 2003.)  We'd be happy
> to package this version up and make it available if people express
> interest in this.

sure I'm interested *expressing interest*

thanks for the info,

TIA,
Herbert

> BTW, if anyone who's using the 2003_04_14 release has found any
> problems, please do let me know and I'll pass the information on to the
> toolchain guys.
> 
> -- 
> Richard \\\ SH-4/SH-5 Core & Debug Architect
> Curnow  \\\         SuperH (UK) Ltd, Bristol
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: Kernel Cross Compiling [update]

[Richard Curnow]

On Mon, 23 Feb, 2004 at  3:41pm, Herbert Poetzl wrote:
> On Mon, Feb 23, 2004 at 01:28:19PM +0000, Richard Curnow wrote:
> > 
> > The last public release we made of the SH-5 tools is available at
> > 
> >     ftp://ftp.uk.superh.com/pub/SuperH-GNU/Barcelona-20030414
> 
> how are they related to the 'mainline' toolchain?

This release equated to something like gcc 3.2.1 + some work from the
3.3 branch + some in-house work.

> i.e. is this something completely separate, or do you follow the
> binutils/gcc updates from time to time?

No, it's not completely separate.  We do follow the mainline tree
(largely via gcc CVS rather than released tarballs), though we tend to
have fairly long periods between such 'rebaselinings'.

> what would be the binutils/gcc version which is 'closest' to 'your'
> toolchain? wouldn't it make sense to get those changes back into the
> mainline?

A lot of changes have already gone into the mainline gcc 3.4 branch.

As for binutils, I assume the position is similar, but I've not checked
the details.

> > The SH-5 tools we're currently using in-house are a few months more
> > advanced than those.  (They date from about August 2003.)  We'd be
> > happy to package this version up and make it available if people
> > express interest in this.
> 
> sure I'm interested *expressing interest*

OK.  Acknowleged.  BTW that version has the same basic ancestry as the
April 14th version, it just has some additional in-house fixes in it.

HTH
Richard

-- 
Richard \\\ SH-4/SH-5 Core & Debug Architect
Curnow  \\\         SuperH (UK) Ltd, Bristol

Re: Kernel Cross Compiling [update]

[Jim Wilson]

On Sat, 2004-02-21 at 19:53, Herbert Poetzl wrote:
> Here is an update to the Kernel Cross Compiling thread 
> I started ten days ago ...

If you want gcc to be fixed so the inhibit_libc builds work for linux
targets, then I suggest opening an FSF gcc bugzilla bug report.  Sending
mail to me or to the linux kernel mailing list is unlikely to accomplish
this.

FYI David Mosberger sent me a comment in private mail pointing out that
if you are trying to bootstrap linux on a new target, then requiring a
glibc port before the kernel port is a problem.  I consider this a good
reason to make this feature work.

However, my recommendation still stands.  In general, I do not recommend
building inhibit_libc crosses for linux targets, even though such
crosses are likely to work fine for building a kernel.  As a gcc
maintainer, it makes my job harder when people are building the compiler
different ways, because I may get bug reports that I can't reproduce or
understand.  Also, there is a risk that a kernel-only cross compiler
will accidentally be used for some other purpose, resulting in a bug
report that wastes the time of the gcc maintainers.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: Kernel Cross Compiling [update]

[Herbert Poetzl]

On Mon, Feb 23, 2004 at 11:42:31AM -0800, Jim Wilson wrote:
> On Sat, 2004-02-21 at 19:53, Herbert Poetzl wrote:
> > Here is an update to the Kernel Cross Compiling thread 
> > I started ten days ago ...
> 
> If you want gcc to be fixed so the inhibit_libc builds work for linux
> targets, then I suggest opening an FSF gcc bugzilla bug report.  Sending
> mail to me or to the linux kernel mailing list is unlikely to accomplish
> this.

hmm, sorry, I didn't want to tantalize you with mails,
I just thought you would be interested in them ...

my apologies here, will avoid further mails to your account

my primary goal isn't to get this fixed by the gcc folks,
I want to have a simple and working solution, which seems
to be at hand for the toolchains, to cross compile the
linux kernel for testing purposes. the changes so far are
not very intrusive IMHO, and I can live with a few patches.
(btw. currently Dan Kegel has a lot more patches to gcc in 
his toolchain than I do)

> FYI David Mosberger sent me a comment in private mail pointing out that
> if you are trying to bootstrap linux on a new target, then requiring a
> glibc port before the kernel port is a problem.  I consider this a good
> reason to make this feature work.

sounds reasonable ... at least to me ;)

> However, my recommendation still stands.  In general, I do not recommend
> building inhibit_libc crosses for linux targets, even though such
> crosses are likely to work fine for building a kernel.  As a gcc
> maintainer, it makes my job harder when people are building the compiler
> different ways, because I may get bug reports that I can't reproduce or
> understand.  Also, there is a risk that a kernel-only cross compiler
> will accidentally be used for some other purpose, resulting in a bug
> report that wastes the time of the gcc maintainers.

originally I had the weird? opinion, that gcc (or it's
build system) does support the cross target to exactly
do this (building an initial gcc, which can be used to
compile other stuff, like (g)libc and such) ...

that this looks like some kind of hack is neither my fault
nor does it justify messing around with 'unbuildable'
(g)libcs to get a kernel cross compile working ...

best,
Herbert

> -- 
> Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: Kernel Cross Compiling [update]

[Dan Kegel]

Herbert Poetzl wrote:
> my primary goal isn't to get this fixed by the gcc folks,
> I want to have a simple and working solution, which seems
> to be at hand for the toolchains, to cross compile the
> linux kernel for testing purposes. the changes so far are
> not very intrusive IMHO, and I can live with a few patches.
> (btw. currently Dan Kegel has a lot more patches to gcc in 
> his toolchain than I do)

My crosstool package has very, very few patches, and each patch is carefully documented.
(You can see them at http://kegel.com/crosstool/current/patches/gcc-3.3.2/ )
The patches that end in -test.patch simply add testcases to the gcc
regression test.  Several of the other patches simply fix testsuite problems.
The only patches that actually affect gcc are

http://kegel.com/crosstool/current/patches/gcc-3.3.2/gcc-3.3.2-arm-softfloat.patch
http://kegel.com/crosstool/current/patches/gcc-3.3.2/sh-lib1funcs_sizeAndType.patch
http://kegel.com/crosstool/current/patches/gcc-3.3.2/sh-libgcc-hidden.patch
http://kegel.com/crosstool/current/patches/gcc-3.3.2/sh-pic-set_fpscr-gcc-3.3.2.patch

I only add a patch after I have verified that it fixes a problem,
and I document what that problem is at the top of the patch;
when possible, the patch starts with a link to gcc's bugzilla for
the problem it fixes.
Fairly often, my patches are simply backports from cvs.

Debian, by comparison, builds gcc with huge collections of patches that are not
documented at all.  Likewise, Red Hat uses quite a few patches.
I don't want to say the Debian and Red Hat compilers are bad,
but I *do* want to say that crosstool builds compilers that are
extremely close to vanilla, with all departures from vanilla carefully documented.

By the way, I agree with Jim Wilson's remark:
 > As a gcc
 > maintainer, it makes my job harder when people are building the compiler
 > different ways, because I may get bug reports that I can't reproduce or
 > understand.  Also, there is a risk that a kernel-only cross compiler
 > will accidentally be used for some other purpose, resulting in a bug
 > report that wastes the time of the gcc maintainers.

That's why I suspect crosstool is a good toolchain for anyone who
wants to report bugs to the gcc folks; it's tightly controlled,
very close to vanilla, and has support for (gasp) running the gcc
and glibc testsuites in a cross-development environment.

- Dan

-- 
US citizens: if you're considering voting for Bush, look at these first:
http://www.misleader.org/
http://www.cbc.ca/news/background/arar/
http://www.house.gov/reform/min/politicsandscience/

Re: Kernel Cross Compiling [update]

[Herbert Poetzl]

On Mon, Feb 23, 2004 at 05:49:29PM -0800, Dan Kegel wrote:
> Herbert Poetzl wrote:
> >my primary goal isn't to get this fixed by the gcc folks,
> >I want to have a simple and working solution, which seems
> >to be at hand for the toolchains, to cross compile the
> >linux kernel for testing purposes. the changes so far are
> >not very intrusive IMHO, and I can live with a few patches.
> >(btw. currently Dan Kegel has a lot more patches to gcc in 
> >his toolchain than I do)
> 
> My crosstool package has very, very few patches, and each 
> patch is carefully documented.

damn! It the last thing I wanted to do ...

my dearest apologies, Dan, it was not and is not my intention
to make your work bad in any way, on the contrary, I really 
appreciate what you are doing, and I'm glad that something 
like crosstool exits ...

best,
Herbert

> (You can see them at http://kegel.com/crosstool/current/patches/gcc-3.3.2/ )
> The patches that end in -test.patch simply add testcases to the gcc
> regression test.  Several of the other patches simply fix testsuite 
> problems.
> The only patches that actually affect gcc are
> 
> http://kegel.com/crosstool/current/patches/gcc-3.3.2/gcc-3.3.2-arm-softfloat.patch
> http://kegel.com/crosstool/current/patches/gcc-3.3.2/sh-lib1funcs_sizeAndType.patch
> http://kegel.com/crosstool/current/patches/gcc-3.3.2/sh-libgcc-hidden.patch
> http://kegel.com/crosstool/current/patches/gcc-3.3.2/sh-pic-set_fpscr-gcc-3.3.2.patch
> 
> I only add a patch after I have verified that it fixes a problem,
> and I document what that problem is at the top of the patch;
> when possible, the patch starts with a link to gcc's bugzilla for
> the problem it fixes.
> Fairly often, my patches are simply backports from cvs.
> 
> Debian, by comparison, builds gcc with huge collections of 
> patches that are not
> documented at all.  Likewise, Red Hat uses quite a few patches.
> I don't want to say the Debian and Red Hat compilers are bad,
> but I *do* want to say that crosstool builds compilers that are
> extremely close to vanilla, with all departures from vanilla 
> carefully documented.
> 
> By the way, I agree with Jim Wilson's remark:
> > As a gcc
> > maintainer, it makes my job harder when people are building the compiler
> > different ways, because I may get bug reports that I can't reproduce or
> > understand.  Also, there is a risk that a kernel-only cross compiler
> > will accidentally be used for some other purpose, resulting in a bug
> > report that wastes the time of the gcc maintainers.
> 
> That's why I suspect crosstool is a good toolchain for anyone who
> wants to report bugs to the gcc folks; it's tightly controlled,
> very close to vanilla, and has support for (gasp) running the gcc
> and glibc testsuites in a cross-development environment.
> 
> - Dan
> 
> -- 
> US citizens: if you're considering voting for Bush, look at these first:
> http://www.misleader.org/
> http://www.cbc.ca/news/background/arar/
> http://www.house.gov/reform/min/politicsandscience/

Re: Kernel Cross Compiling [update]

[Arnd Bergmann]

Herbert Poetzl wrote:

>    			   linux-2.6.3-rc3     linux-2.6.3
>    			   config  build       config  build

>    s390/s390:		   OK	   FAILED      OK      FAILED

This trivial patch (or something similar) is missing from 2.6.3
to make it build for s390.

You might also want to test building in 64 bit mode 
(CONFIG_ARCH_S390X on 2.6, ARCH=s390x on 2.4).

     Arnd <><

===== include/asm-s390/dma-mapping.h 1.2 vs edited =====
--- 1.2/include/asm-s390/dma-mapping.h	Thu Jul 17 19:27:29 2003
+++ edited/include/asm-s390/dma-mapping.h	Sun Feb 22 17:15:43 2004
@@ -8,4 +8,20 @@
 
 #ifndef _ASM_DMA_MAPPING_H
 #define _ASM_DMA_MAPPING_H
+
+static inline void *
+dma_alloc_coherent(struct device *dev, size_t size, dma_addr_t
*dma_handle,
+		   int flag)
+{
+	BUG();
+	return 0;
+}
+
+static inline void
+dma_free_coherent(struct device *dev, size_t size, void *cpu_addr,
+		    dma_addr_t dma_handle)
+{
+	BUG();
+}
+
 #endif /* _ASM_DMA_MAPPING_H */