Eric Lee / smarc-uboot

31 Oct, 2009

1 commit

  • c28d3bbe9   video: mb862xx: improve board-specific Lime configuration ... Browse Code »

    To avoid board-specific code accessing the mb862xx registers directly,
    the public function mb862xx_probe() has been introduced. Furthermore,
    the "Change of Clock Frequency" and "Set Memory I/F Mode" registers
    are now defined by CONFIG_SYS_MB862xx_CCF and CONFIG_SYS_MB862xx__MMR,
    respectively. The BSPs for the socrates and lwmon5 boards have been
    adapted accordingly.

    Signed-off-by: Wolfgang Grandegger

    Wolfgang Grandegger
     

25 Sep, 2009

1 commit

  • 002741ae8   ppc/85xx: Clean up use of LAWAR defines ... Browse Code »

    On 85xx platforms we shouldn't be using any LAWAR_* defines
    but using the LAW_* ones provided by fsl-law.h. Rename any such
    uses and limit the LAWAR_ to the 83xx platform as the only user so
    we will get compile errors in the future.

    Signed-off-by: Kumar Gala

    Kumar Gala
     

29 Aug, 2009

1 commit

04 Jun, 2009

1 commit

  • dfcd7f216   Redundant Environment: protect full sector size ... Browse Code »

    Several boards used different ways to specify the size of the
    protected area when enabling flash write protection for the sectors
    holding the environment variables: some used CONFIG_ENV_SIZE and
    CONFIG_ENV_SIZE_REDUND, some used CONFIG_ENV_SECT_SIZE, and some even
    a mix of both for the "normal" and the "redundant" areas.

    Normally, this makes no difference at all. However, things are
    different when you have to deal with boards that can come with
    different types of flash chips, which may have different sector
    sizes.

    Here we may have to chose CONFIG_ENV_SECT_SIZE such that it fits the
    biggest sector size, which may include several sectors on boards using
    the smaller sector flash types. In such a case, using CONFIG_ENV_SIZE
    or CONFIG_ENV_SIZE_REDUND to enable the protection may lead to the
    case that only the first of these sectors get protected, while the
    following ones aren't.

    This is no real problem, but it can be confusing for the user -
    especially on boards that use CONFIG_ENV_SECT_SIZE to protect the
    "normal" areas, while using CONFIG_ENV_SIZE_REDUND for the
    "redundant" area.

    To avoid such inconsistencies, I changed all sucn boards that I found
    to consistently use CONFIG_ENV_SECT_SIZE for protection. This should
    not cause any functional changes to the code.

    Signed-off-by: Wolfgang Denk
    Cc: Paul Ruhland
    Cc: Pantelis Antoniou
    Cc: Stefan Roese
    Cc: Gary Jennejohn
    Cc: Dave Ellis
    Acked-by: Stefan Roese

    Wolfgang Denk
     

21 Mar, 2009

1 commit

  • f62fb9994   Fix all linker script to handle all rodata sections ... Browse Code »

    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
     

20 Dec, 2008

1 commit

  • a5d212a26   mpc8xxx: LCRR[CLKDIV] is sometimes five bits ... Browse Code »

    On newer CPUs, 8536, 8572, and 8610, the CLKDIV field of LCRR is five bits
    instead of four.

    In order to avoid an ifdef, LCRR_CLKDIV is set to 0x1f on all systems. It
    should be safe as the fifth bit was defined as reserved and set to 0.

    Code that was using a hard coded 0x0f is changed to use LCRR_CLKDIV.

    Signed-off-by: Trent Piepho
    Acked-by: Kumar Gala
    Acked-by: Jon Loeliger

    Trent Piepho
     

04 Dec, 2008

1 commit

  • dd332e18d   85xx: socrates: fix DDR SDRAM tlb entry configuration ... Browse Code »

    since commit be0bd8234b9777ecd63c4c686f72af070d886517
    tlb entry for socrates DDR SDRAM will be reconfigured
    by setup_ddr_tlbs() from initdram() causing an
    inconsistency with previously configured DDR SDRAM tlb
    entry from tlb_table:

    socrates>l2cam 7 9
    IDX PID EPN SIZE V TS RPN U0-U3 WIMGE UUUSSS
    7 : 00 00000000 256MB V 0 -> 0_00000000 0000 -I-G- ---RWX
    8 : 00 00000000 256MB V 0 -> 0_00000000 0000 ----- ---RWX
    9 : 00 10000000 256MB V 0 -> 0_10000000 0000 ----- ---RWX

    This patch makes the presence of the DDR SDRAM tlb entry in
    the tlb_table dependent on CONFIG_SPD_EEPROM to avoid this
    inconsistency.

    Signed-off-by: Anatolij Gustschin
    Acked-by: Andy Fleming

    Anatolij Gustschin
     

19 Nov, 2008

1 commit

  • 9b827cf17   Align end of bss by 4 bytes ... Browse Code »

    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

2 commits

23 Sep, 2008

1 commit

13 Sep, 2008

1 commit

11 Sep, 2008

1 commit

09 Sep, 2008

2 commits

  • e64987a89   85xx: socrates: Enable Lime support. ... Browse Code »

    This patch adds Lime GDC support together with support for the PWM
    backlight control through the w83782d chip. The reset pin of the
    latter is attached to GPIO, so we need to reset it in
    early_board_init_r.

    Signed-off-by: Anatolij Gustschin

    Anatolij Gustschin
     
  • 3e79b588b   85xx: Socrates: Major code update. ... Browse Code »

    - Update the local bus ranges in the FDT for Linux for the various
    devices connected to the local bus via chip-select.

    - Set the LCRR_DBYP bit in the LCRR for local bus frequencies
    lower than 66 MHz and uses I/O accessor functions consequently.

    - UPM data update.

    - Update of default environment and configuration. Use I2C multibus
    as we do have two I2C buses. Also enable sdram and ext2 commands.

    Signed-off-by: Wolfgang Grandegger
    Signed-off-by: Sergei Poselenov
    Signed-off-by: Detlev Zundel

    Detlev Zundel
     

28 Aug, 2008

1 commit

14 Aug, 2008

1 commit

03 Jul, 2008

1 commit

29 Jun, 2008

1 commit

12 Jun, 2008

1 commit

  • 9973e3c61   Change initdram() return type to phys_size_t ... Browse Code »

    This patch changes the return type of initdram() from long int to phys_size_t.
    This is required for a couple of reasons: long int limits the amount of dram
    to 2GB, and u-boot in general is moving over to phys_size_t to represent the
    size of physical memory. phys_size_t is defined as an unsigned long on almost
    all current platforms.

    This patch *only* changes the return type of the initdram function (in
    include/common.h, as well as in each board's implementation of initdram). It
    does not actually modify the code inside the function on any of the platforms;
    platforms which wish to support more than 2GB of DRAM will need to modify
    their initdram() function code.

    Build tested with MAKEALL for ppc, arm, mips, mips-el. Booted on powerpc
    MPC8641HPCN.

    Signed-off-by: Becky Bruce

    Becky Bruce
     

11 Jun, 2008

6 commits

27 May, 2008

1 commit

21 May, 2008

2 commits