[okl4-developer] OKL4 2.1: Original version of'arch/arm/pistachio/cpu/arm926ejs/include/cache.h' is not compilable

[Geoffrey Lee]

On Wed, Jul 09, 2008 at 06:59:44PM +0200, Frank Kaiser wrote:
> Hello, Folks

Hi Frank

> 
>  
> 
> It turned out that the below mentioned statement
>              'static const word_t CACHE_LINE_MASK = (CACHE_LINE_SIZE -
> 1)'
> is not only superfluous, but is fatal to the build. It creates a number
> of loader errors of the sort:
> 
> arm-linux-ld: sam/pistachio/bin/kernel: warning: allocated section
> `.text' not in segment
> 
> arm-linux-ld: sam/pistachio/bin/kernel: warning: allocated section
> `.glue_7' not in segment
> 
> arm-linux-ld: sam/pistachio/bin/kernel: warning: allocated section
> `.glue_7t' not in segment
> 
> ...
> 
> I can only guess that this has something to do with the fact that the
> statement creates a code allocation in any source files which includes
> 'cache.h'. Commenting the statement out heals the problem.
> 


Thanks for letting us know and keeping us updated on your latest
progress.  Your reports are greatly appreciated.

 
>  
> 
> Regards
> 
> Frank

	-gl

> 
> From: developer-bounces at okl4.org [mailto:developer-bounces at okl4.org] On
> Behalf Of Frank Kaiser
> Sent: Wednesday, July 09, 2008 4:31 PM
> To: developer at okl4.org
> Subject: [okl4-developer] OKL4 2.1: Original version
> of'arch/arm/pistachio/cpu/arm926ejs/include/cache.h' is not compilable
> 
>  
> 
> Hello
> 
>  
> 
> When I started my platform development, I drew the okl4_2.1.tar.gz
> tarball from http://wiki.ok-labs.com/FrontPage?action=AttachFile.
> Unzipping it, for some reason, I did not get out the core specific
> include files 'cache.h', 'cpu.h' and 'syscon.h' located at
> 'arch/arm/pistachio/cpu/arm926ejs/include/'. Since there is no example
> platform in the tarball using the ARM926EJ-S core, I thought they were
> left out intentionally, and I created my own ones by combining the
> XSCALE and ARM920T variants with ARM926EJ-S variants from OKL4 1.4.9. It
> just did not occur to me that the unzip went wrong.
> 
> Meanwhile a colleague also used the mentioned tarball and put it in our
> SVN repository. Recently I began to integrate my new platform code into
> the SVN repository and discovered the missing header file. Comparing
> them with my own creation showed that I have some insignificant
> differences with 'cpu.h' and 'syscon.h', but a significant difference in
> the referenced header files with 'cache.h'.
> 
> Here the include statements of the original:
> 
> #include <debug.h>
> 
> #include <cpu/syscon.h>
> 
> #include <cache.h>
> 
> #include <plat/platform.h> /* Get cache size */
> 
> Here the include statements of my private version:
> 
>              #include <kernel/debug.h>
> 
> #include <kernel/arch/asm.h>
> 
> #include <kernel/cpu/syscon.h>
> 
> Another difference is that the original version contains the definition 
>              'static const word_t CACHE_LINE_MASK = (CACHE_LINE_SIZE -
> 1)' 
> which does not exist in my private version, and I do not see that
> CACHE_LINE_MASK is anywhere referenced.
> 
> My private version compiles w/o a flaw, but the original one files for
> the first compiled source file (asid.cc) with the following multiple
> error:
> 
> sam/pistachio/include/kernel/cpu/cache.h: In static member function
> `static void arm_cache::cache_flush_i()':
> 
> sam/pistachio/include/kernel/cpu/cache.h:150: error: expected `)' before
> "_"
> 
> sam/pistachio/include/kernel/cpu/cache.h:148: warning: unused variable
> 'zero'
> 
> The relevant code lines are:
> 
>         __asm__ __volatile__ (
> 
>              "  mcr     p15, 0, "_(zero)", c7, c5, 0    ;"      /* Flush
> I cache */
> 
> #if defined(__GNUC__)
> 
>             :: [zero] "r" (zero)
> 
> #endif
> 
> The problem is that '_()' is a preprocessor macro defined in
> 'kernel/arch/asm.h' which the original file misses.
> 
> I made the addition to the original file by following its include path
> scheme:
> 
> #include <debug.h>
> 
> #include <arch/asm.h>
> 
> #include <cpu/syscon.h>
> 
> #include <cache.h>
> 
> #include <plat/platform.h> /* Get cache size */
> 
> Surprisingly this correction does not work. I get most of the files of
> the PISTACHIO kernel compiled until it comes to the platform specific
> ones. With 'platform/at91/pistachio/src/interrupt.cc' the error
> reappears, and additionally the compiler claims that it does not find
> the header files 'debug.h', 'arch/asm.h', 'cpu/syscon.h', 'cache.h' and
> 'plat/platform.h', the 5 ones included by
> '.../arm926ejs/include/cache.h'. Something must we wrong the the include
> paths seen by the compiler, and a view in the log shows the difference.
> 
> When compiling, for instance 'asid.cc', the include paths are ('sam' is
> the build directory):
> 
> -Isam/pistachio/include 
> 
> -Isam/pistachio/object/pistachio/include 
> 
> -Ipistachio/include 
> 
> -Iarch/arm/pistachio/v5/include
> 
> However, for 'interrupt.cc' the include paths are:
> 
> -Isam/pistachio/include 
> 
> -Isam/pistachio/object/pistachio/src 
> 
> -Ipistachio/src
> 
> Both files share only the first include paths of both list. Checking
> this location shows that 'asm.h' is found at
> 'sam/pistachio/include/kernel/arch'. That explains why my private
> version of 'cache.h' finds it. But when compiling 'asid.cc' the original
> version finds it too, and that is thru the second include path
> 'sam/pistachio/object/pistachio/include' under which copy of the arch
> directory exists. It looks as if there is a mix-up of include paths
> versus header file copies in the build directory. The question is:
> 
> *       Why are there different include paths for the pistachio kernel
> source files and for the platform-dependent source files?
> 
> *       Why are there two copies of the architectural-, cpu-, kdb- and
> platform-specific header files, one set in
> '<build_dir>/pistachio/include/kernel' and one set in
> '<build_dir>/pistachio/object/pistachio/include'?
> 
> Although the copies are created by SCONS, it is confusing regarding the
> correct set-up of #include directives in the source file. If I had to
> write my platform source files totally from scratch, I'd have had a hard
> time with this. Actually I made a test compilation with an existing
> platform to figure out how the build directory looks like after a
> successful build.
> 
>  
> 
> Regards
> 
> Frank
> 

> _______________________________________________
> Developer mailing list
> Developer at okl4.org
> https://lists.okl4.org/mailman/listinfo/developer


--