08 May, 2007

1 commit

  • This adds support for the Analog Devices Blackfin processor architecture, and
    currently supports the BF533, BF532, BF531, BF537, BF536, BF534, and BF561
    (Dual Core) devices, with a variety of development platforms including those
    avaliable from Analog Devices (BF533-EZKit, BF533-STAMP, BF537-STAMP,
    BF561-EZKIT), and Bluetechnix! Tinyboards.

    The Blackfin architecture was jointly developed by Intel and Analog Devices
    Inc. (ADI) as the Micro Signal Architecture (MSA) core and introduced it in
    December of 2000. Since then ADI has put this core into its Blackfin
    processor family of devices. The Blackfin core has the advantages of a clean,
    orthogonal,RISC-like microprocessor instruction set. It combines a dual-MAC
    (Multiply/Accumulate), state-of-the-art signal processing engine and
    single-instruction, multiple-data (SIMD) multimedia capabilities into a single
    instruction-set architecture.

    The Blackfin architecture, including the instruction set, is described by the
    ADSP-BF53x/BF56x Blackfin Processor Programming Reference
    http://blackfin.uclinux.org/gf/download/frsrelease/29/2549/Blackfin_PRM.pdf

    The Blackfin processor is already supported by major releases of gcc, and
    there are binary and source rpms/tarballs for many architectures at:
    http://blackfin.uclinux.org/gf/project/toolchain/frs There is complete
    documentation, including "getting started" guides available at:
    http://docs.blackfin.uclinux.org/ which provides links to the sources and
    patches you will need in order to set up a cross-compiling environment for
    bfin-linux-uclibc

    This patch, as well as the other patches (toolchain, distribution,
    uClibc) are actively supported by Analog Devices Inc, at:
    http://blackfin.uclinux.org/

    We have tested this on LTP, and our test plan (including pass/fails) can
    be found at:
    http://docs.blackfin.uclinux.org/doku.php?id=testing_the_linux_kernel

    [m.kozlowski@tuxland.pl: balance parenthesis in blackfin header files]
    Signed-off-by: Bryan Wu
    Signed-off-by: Mariusz Kozlowski
    Signed-off-by: Aubrey Li
    Signed-off-by: Jie Zhang
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Bryan Wu
     

25 Jun, 2006

2 commits

  • We have had no use of the coredump file for a long time.
    So just exit(1) and avoid coredumping.

    Signed-off-by: Sam Ravnborg

    Sam Ravnborg
     
  • Here is a patch that adds a new -T option to genksyms for generating dumps of
    the type definition that makes up the symbol version hashes. This allows to
    trace modversion changes back to what caused them. The dump format is the
    name of the type defined, followed by its definition (which is almost C):

    s#list_head struct list_head { s#list_head * next , * prev ; }

    The s#, u#, e#, and t# prefixes stand for struct, union, enum, and typedef.
    The exported symbols do not define types, and thus do not have an x# prefix:

    nfs4_acl_get_whotype int nfs4_acl_get_whotype ( char * , t#u32 )

    The symbol type defintion of a single file can be generated with:

    make fs/jbd/journal.symtypes

    If KBUILD_SYMTYPES is defined, all the *.symtypes of all object files that
    export symbols are generated.

    The single *.symtypes files can be combined into a single file after a kernel
    build with a script like the following:

    for f in $(find -name '*.symtypes' | sort); do
    f=${f#./}
    echo "/* ${f%.symtypes}.o */"
    cat $f
    echo
    done \
    | sed -e '\:UNKNOWN:d' \
    -e 's:[,;] }:}:g' \
    -e 's:\([[({]\) :\1:g' \
    -e 's: \([])},;]\):\1:g' \
    -e 's: $::' \
    $f \
    | awk '
    /^.#/ { if (defined[$1] == $0) {
    print $1
    next
    }
    defined[$1] = $0
    }
    { print }
    '

    When the kernel ABI changes, diffing individual *.symtype files, or the
    combined files, against each other will show which symbol changes caused the
    ABI changes. This can save a tremendous amount of time.

    Dump the types that make up modversions

    Signed-off-by: Andreas Gruenbacher
    Signed-off-by: Sam Ravnborg

    Andreas Gruenbacher
     

26 Mar, 2006

1 commit

  • * master.kernel.org:/pub/scm/linux/kernel/git/sam/kbuild: (46 commits)
    kbuild: remove obsoleted scripts/reference_* files
    kbuild: fix make help & make *pkg
    kconfig: fix time ordering of writes to .kconfig.d and include/linux/autoconf.h
    Kconfig: remove the CONFIG_CC_ALIGN_* options
    kbuild: add -fverbose-asm to i386 Makefile
    kbuild: clean-up genksyms
    kbuild: Lindent genksyms.c
    kbuild: fix genksyms build error
    kbuild: in makefile.txt note that Makefile is preferred name for kbuild files
    kbuild: replace PHONY with FORCE
    kbuild: Fix bug in crc symbol generating of kernel and modules
    kbuild: change kbuild to not rely on incorrect GNU make behavior
    kbuild: when warning symbols exported twice now tell user this is the problem
    kbuild: fix make dir/file.xx when asm symlink is missing
    kbuild: in the section mismatch check try harder to find symbols
    kbuild: fix section mismatch check for unwind on IA64
    kbuild: kill false positives from section mismatch warnings for powerpc
    kbuild: kill trailing whitespace in modpost & friends
    kbuild: small update of allnoconfig description
    kbuild: make namespace.pl CROSS_COMPILE happy
    ...

    Trivial conflict in arch/ppc/boot/Makefile manually fixed up

    Linus Torvalds
     

21 Mar, 2006

1 commit


13 Mar, 2006

3 commits

  • o remove all inlines
    o declare everything static which is only used by genksyms.c
    o delete unused functions
    o delete unused variables
    o delete unused stuff in genksyms.h
    o properly ident genksyms.h

    Signed-off-by: Sam Ravnborg

    Sam Ravnborg
     
  • No fix-ups applied yet. Just the raw Lindent output.

    Signed-off-by: Sam Ravnborg

    Sam Ravnborg
     
  • genksyms needs to know when a symbol must have a "_" prefex as is
    true for a few architectures.
    Pass $(ARCH) as commandline argument and hardcode what architectures that
    needs this info.
    Previous attemt to take it from elfconfig.h was br0ken since elfconfig.h
    is a generated file.

    Signed-off-by: Sam Ravnborg

    Sam Ravnborg
     

09 Mar, 2006

1 commit

  • The scripts/genksyms/genksyms.c uses hardcoded "__crc_" prefix for
    crc symbols in kernel and modules. The prefix should be replaced by
    "MODULE_SYMBOL_PREFIX##__crc_" otherwise there will be warnings when
    MODULE_SYMBOL_PREFIX is not NULL.

    I am sorry my last patch for this issue is actually wrong. I revert
    it in this patch.

    Signed-off-by: Luke Yang
    Signed-off-by: Sam Ravnborg

    Luke Yang
     

02 Jan, 2006

1 commit


27 Dec, 2005

2 commits

  • Generate _shipped files so the genksyms change in previous commit is enabled.
    The files are generated with latest versions of the tools:

    bison (GNU Bison) 2.0
    flex version 2.5.4
    GNU gperf 3.0.1

    Signed-off-by: Sam Ravnborg

    Sam Ravnborg
     
  • This is a one-line change to parse.y.
    To take advantage of this the scripts/genksyms/*_shipped files needs to
    be rebuild - this is the next patch.

    When a .c file contains:
    DEFINE_PER_CPU(struct foo_s *, bar);

    the .cpp output looks like:
    __attribute__((__section__(".data.percpu"))) __typeof__(struct foo_s *) per_cpu__bar;

    With the existing parse.y, the value inside the paranthesis of
    __typeof__() does not evaluate as a type_specifier and therefore
    per_cpu__bar does not get assigned a type for genksyms which results in
    the EXPORT_PER_CPU_SYMBOL() not generating a CRC value.

    I have compared the Modules.symvers with and without this
    patch and for ia64's defconfig, the only change is:
    Before 0x00000000 per_cpu____sn_nodepda vmlinux
    After 0x9d3f3faa per_cpu____sn_nodepda vmlinux

    per_cpu____sn_nodepda was the original source of my problems.

    Signed-off-by: Robin Holt
    Signed-off-by: Sam Ravnborg

    Robin Holt
     

17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds