07 May, 2018

1 commit

  • When U-Boot started using SPDX tags we were among the early adopters and
    there weren't a lot of other examples to borrow from. So we picked the
    area of the file that usually had a full license text and replaced it
    with an appropriate SPDX-License-Identifier: entry. Since then, the
    Linux Kernel has adopted SPDX tags and they place it as the very first
    line in a file (except where shebangs are used, then it's second line)
    and with slightly different comment styles than us.

    In part due to community overlap, in part due to better tag visibility
    and in part for other minor reasons, switch over to that style.

    This commit changes all instances where we have multiple licenses (in
    these cases, dual license) declared in the SPDX-License-Identifier tag.
    In this case we change from listing "LICENSE-A LICENSE-B" or "LICENSE-A
    or LICENSE-B" or "(LICENSE-A OR LICENSE-B)" to "LICENSE-A OR LICENSE-B"
    as per the Linux Kernel style document. Note that parenthesis are
    allowed so when they were used before we continue to use them.

    Reviewed-by: Fabio Estevam
    Signed-off-by: Tom Rini

    Tom Rini
     

06 May, 2017

1 commit


28 Dec, 2016

1 commit


13 Feb, 2014

1 commit


09 Jan, 2014

1 commit

  • ARM64 uses the newer RELA-style relocations rather than the older REL.
    RELA relocations have an addend in the relocation struct, rather than
    expecting the loader to read a value from the location to be updated.

    While this is beneficial for ordinary program loading, it's problematic
    for U-Boot because the location to be updated starts out with zero,
    rather than a pre-relocation value. Since we need to be able to run C
    code before relocation, we need a tool to apply the relocations at
    build time.

    In theory this tool is applicable to other newer architectures (mainly
    64-bit), but currently the only relocations it supports are for arm64,
    and it assumes a 64-bit little-endian target. If the latter limitation
    is ever to be changed, we'll need a way to tell the tool what format
    the image is in. Eventually this may be replaced by a tool that uses
    libelf or similar and operates directly on the ELF file. I've written
    some code for such an approach but libelf does not make it easy to poke
    addresses by memory address (rather than by section), and I was
    hesitant to write code to manually parse the program headers and do the
    update outside of libelf (or to iterate over sections) -- especially
    since it wouldn't get test coverage on things like binaries with
    multiple PT_LOAD segments. This should be good enough for now to let
    the manual relocation stuff be removed from the arm64 patches.

    Signed-off-by: Scott Wood
    Signed-off-by: David Feng

    Scott Wood