13 Nov, 2009

1 commit


27 Oct, 2009

1 commit


05 Oct, 2009

1 commit

  • All in-tree boards that use this controller have CONFIG_NET_MULTI
    added
    Also:
    - changed CONFIG_DRIVER_SMC91111 to CONFIG_SMC91111
    - cleaned up line lengths
    - modified all boards that override weak function in this driver
    - modified all eeprom standalone apps to work with new driver
    - updated blackfin standalone EEPROM app after testing

    Signed-off-by: Ben Warren
    Signed-off-by: Mike Frysinger

    Ben Warren
     

16 Sep, 2009

1 commit


05 Sep, 2009

2 commits

  • Rather than maintain/extend the current ifeq($(ARCH)) mess that exists in
    the standalone Makefile, push the setting up of LOAD_ADDR out to the arch
    config.mk (and rename to STANDALONE_LOAD_ADDR in the process). This keeps
    the common code clean and lets the arch do whatever crazy crap it wants in
    its own area.

    Signed-off-by: Mike Frysinger

    Mike Frysinger
     
  • Atmel DataFlashes by default operate with pages that are slightly bigger
    than normal binary sizes (i.e. many are 1056 byte pages rather than 1024
    bytes). However, they also have a "power of 2" mode where the pages show
    up with the normal binary size. The latter mode is required in order to
    boot with a Blackfin processor, so many people wish to convert their
    DataFlashes on their development systems to this mode. This standalone
    application does just that.

    Signed-off-by: Mike Frysinger

    Mike Frysinger
     

02 Sep, 2009

1 commit

  • Since the Blackfin ABI favors higher scratch registers by default, use the
    last scratch register (P3) for global data rather than the first (P5).
    This allows the compiler's register allocator to use higher number scratch
    P registers, which in turn better matches the Blackfin instruction set,
    which reduces the size of U-Boot by more than 1024 bytes...

    Signed-off-by: Robin Getz
    Signed-off-by: Mike Frysinger

    Robin Getz
     

08 Aug, 2009

1 commit

  • The attached patch corrects an error in the examples/Makefile which
    causes the applications in the examples directory to hang on OMAP3
    based boards. The current Makefile sets -Ttext during linking to
    0x0c100000 which is outside of addressable SDRAM memory. The script
    corrects the existing ifeq...else...endif logic to look at the VENDOR
    tag rather than the CPU tag.

    The patch affects the following configs: omap3_beagle_config,
    omap3_overo_config, omap3_evm_config, omap3_pandora_config,
    omap3_zoom1_config and omap3_zoom2_config.

    Signed-off-by: Michael Evans

    Edited commit message.
    Signed-off-by: Wolfgang Denk

    Michael Evans
     

27 Jul, 2009

1 commit


21 Jul, 2009

2 commits


05 Apr, 2009

1 commit


21 Mar, 2009

1 commit

  • A recent gcc added a new unaligned rodata section called '.rodata.str1.1',
    which needs to be added the the linker script. Instead of just adding this
    one section, we use a wildcard ".rodata*" to get all rodata linker section
    gcc has now and might add in the future.

    However, '*(.rodata*)' by itself will result in sub-optimal section
    ordering. The sections will be sorted by object file, which causes extra
    padding between the unaligned rodata.str.1.1 of one object file and the
    aligned rodata of the next object file. This is easy to fix by using the
    SORT_BY_ALIGNMENT command.

    This patch has not be tested one most of the boards modified. Some boards
    have a linker script that looks something like this:

    *(.text)
    . = ALIGN(16);
    *(.rodata)
    *(.rodata.str1.4)
    *(.eh_frame)

    I change this to:

    *(.text)
    . = ALIGN(16);
    *(.eh_frame)
    *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*)))

    This means the start of rodata will no longer be 16 bytes aligned.
    However, the boundary between text and rodata/eh_frame is still aligned to
    16 bytes, which is what I think the real purpose of the ALIGN call is.

    Signed-off-by: Trent Piepho

    Trent Piepho
     

19 Mar, 2009

1 commit


23 Feb, 2009

1 commit

  • A forward port of the last version to work with the newer smc911x driver.
    I only have a board with a LAN9218 part on it, so that is the only one
    I've tested. But there isn't anything in this that would make it terribly
    chip specific afaik.

    Signed-off-by: Mike Frysinger
    CC: Sascha Hauer
    CC: Guennadi Liakhovetski
    CC: Magnus Lilja
    Signed-off-by: Ben Warren

    Mike Frysinger
     

25 Jan, 2009

1 commit


10 Dec, 2008

1 commit


19 Nov, 2008

1 commit

  • Most of the bss initialization loop increments 4 bytes
    at a time. And the loop end is checked for an 'equal'
    condition. Make the bss end address aligned by 4, so
    that the loop will end as expected.

    Signed-off-by: Selvamuthukumar
    Signed-off-by: Wolfgang Denk

    Selvamuthukumar
     

19 Oct, 2008

1 commit


14 Oct, 2008

1 commit


09 Sep, 2008

1 commit


31 Aug, 2008

1 commit


11 Jul, 2008

1 commit


10 Jul, 2008

1 commit


21 May, 2008

1 commit

  • This commit gets rid of a huge amount of silly white-space issues.
    Especially, all sequences of SPACEs followed by TAB characters get
    removed (unless they appear in print statements).

    Also remove all embedded "vim:" and "vi:" statements which hide
    indentation problems.

    Signed-off-by: Wolfgang Denk

    Wolfgang Denk
     

19 May, 2008

1 commit


08 Apr, 2008

1 commit


12 Mar, 2008

1 commit


04 Mar, 2008

1 commit


03 Mar, 2008

1 commit


22 Feb, 2008

1 commit


17 Feb, 2008

1 commit


15 Feb, 2008

2 commits


07 Feb, 2008

1 commit


05 Feb, 2008

4 commits


13 Jan, 2008

1 commit

  • With recent toolchain versions, some boards would not build because
    or errors like this one (here for ocotea board when building with
    ELDK 4.2 beta):
    ppc_4xx-ld: section .bootpg [fffff000 -> fffff23b] overlaps section .bss [fffee900 -> fffff8ab]

    For many boards, the .bss section is big enough that it wraps around
    at the end of the address space (0xFFFFFFFF), so the problem will not
    be visible unless you use a 64 bit tool chain for development. On
    some boards however, changes to the code size (due to different
    optimizations) we bail out with section overlaps like above.

    The fix is to add the NOLOAD attribute to the .bss and .sbss
    sections, telling the linker that .bss does not consume any space in
    the image.

    Signed-off-by: Wolfgang Denk

    Wolfgang Denk