10 Apr, 2015

1 commit

  • This is important to have entry point in the beginning of .text section
    because it allows simple loading and execution of U-Boot.

    For example pre-bootloader loads U-Boot in memory starting from offset
    0x81000000 and then just jumps to the same address.

    Otherwise pre-bootloader would need to find-out where entry-point is. In
    its turn if it deals with binary image of U-Boot there's no way for
    pre-bootloader to get required value.

    Signed-off-by: Alexey Brodkin

    Alexey Brodkin
     

03 Apr, 2015

3 commits

  • Intention behind this work was elimination of as much assembly-written
    code as it is possible.

    In case of ARC we already have relocation fix-up implemented in C so why
    don't we use C for U-Boot copying, .bss zeroing etc.

    It turned out x86 uses pretty similar approach so we re-used parts of
    code in "board_f.c" initially implemented for x86.

    Now assembly usage during init is limited to stack- and frame-pointer
    setup before and after relocation.

    Signed-off-by: Alexey Brodkin
    Cc: Simon Glass

    Alexey Brodkin
     
  • This separation makes maintenance of code easier because those low-level
    interrupt- or exception handling routines are pretty static and usually
    require not much care while start-up code is a subject of modifications
    and enhancements.

    Signed-off-by: Alexey Brodkin

    Alexey Brodkin
     
  • Even though ARCompact and ARCv2 are not binary compatible most of
    assembly instructions are used in both. With this change we'll get rid
    of duplicate code.

    Still IVTs are implemented differently so we're keeping them in separate
    files.

    Signed-off-by: Alexey Brodkin

    Alexey Brodkin
     

09 Feb, 2015

1 commit

  • This way we may have very limited set of functions implemented so we
    save some space.

    Also it allows us to build U-Boot for any ARC core with the same one
    toolchain because we don't rely on pre-built libgcc.

    For example:
    * we may use little-endian toolchain but build U-Boot for ether
    endianess
    * we may use non-multilibbed uClibc toolchain but build U-Boot for
    whatever ARC CPU flavour that current GCC supports

    Private libgcc built from generic C implementation contributes only 144
    bytes to .text section so we don't see significant degradation of size:
    --->8---
    $ arc-linux-size u-boot.libgcc-prebuilt
    text data bss dec hex filename
    222217 24912 214820 461949 70c7d u-boot.libgcc-prebuilt

    $ arc-linux-size u-boot.libgcc-private
    text data bss dec hex filename
    222361 24912 214820 462093 70d0d u-boot.libgcc-private
    --->8---

    Also I don't notice visible performance degradation compared to
    pre-built libgcc (where at least "*div*" functions are had-written in
    assembly) on typical operations of downloading 10Mb uImage over TFTP and
    bootm.

    Signed-off-by: Alexey Brodkin

    Alexey Brodkin
     

16 Jan, 2015

1 commit

  • "reset.c" and "cpu.c" have no architecture-specific code at all.
    Others are applicable to either ARC CPU.

    This change is a preparation to submission of ARCv2 architecture port.

    Even though ARCv1 and ARCv2 ISAs are not binary compatible most of
    built-in modules still have the same programming model - AUX registers
    are mapped in the same addresses and hold the same data (new featues
    extend existing ones).

    So only low-level assembly code (start-up, interrupt handlers) is left
    as CPU(actually ISA)-specific. This significantyl simplifies maintenance
    of multiple CPUs/ISAs.

    Signed-off-by: Alexey Brodkin
    Signed-off-by: Igor Guryanov

    Alexey Brodkin
     

07 Feb, 2014

1 commit