08 Apr, 2015

1 commit

  • Since commit 32df39c741788e ("mx5: fix get_reset_cause") we have the following
    boot messages on a mx53qsb:

    U-Boot 2015.04-rc5-00029-gd68df02 (Apr 06 2015 - 11:15:39)

    CPU: Freescale i.MX53 rev2.1 at 800 MHz
    Reset cause: POR
    Board: MX53 LOCO
    I2C: ready
    DRAM: 1 GiB
    MMC: FSL_SDHC: 0, FSL_SDHC: 1
    In: serial
    Out: serial
    Err: serial
    CPU: Freescale i.MX53 rev2.1 at 1000 MHz
    Reset cause: unknown reset
    Net: FEC [PRIME]

    The CPU and Reset cause lines appear twice.

    Initially mx53 boots at 800MHz, then at a later point the PMIC is configured via
    I2C to raise the CPU voltage so that it can run at 1GHz.

    To avoid such misleading double printings, disable printing cpu info for now.

    Signed-off-by: Fabio Estevam
    Acked-by: Jason Liu

    Fabio Estevam
     

13 Mar, 2015

1 commit

  • Entering the maximum number of characters defined by CONFIG_SYS_CBSIZE into
    the console and hitting enter afterwards, causes a hang in the system because
    CONFIG_SYS_PBSIZE is not capable of storing the extra characters of the error
    message:
    "Unknown command '' - try 'help'".

    Use the default CONFIG_SYS_PBSIZE definition from config_fallbacks.h to solve
    this problem.

    Cc: Jason Liu
    Signed-off-by: Fabio Estevam
    Acked-by: Jason Liu

    Fabio Estevam
     

05 Mar, 2015

1 commit

  • commit d9f43c8f5c1d7ed27c99a06be85a4bb64b2c73fb sets
    get_reset_cause() as static, but this conflicts with mx5
    where its prototype is in sys_proto.h.

    Drop it from sys_proto.h and drop print_cpuinfo from mx53_loco,
    factorizing the call for this board.

    Signed-off-by: Stefano Babic
    CC: Jason Liu

    Stefano Babic
     

01 Dec, 2014

1 commit


13 Nov, 2014

1 commit

  • Since kernel 3.15 there are two dtb's for the imx53-qsb board:

    imx53-qsb.dtb - For the boards with DA9053 PMIC
    imx53-qsrb.dtb - For the boards with MC34708 PMIC

    Change the 'fdt_file' dynamically, so that the correct dtb can be used depending
    on the board variant.

    Signed-off-by: Fabio Estevam
    Acked-by: Otavio Salvador

    Fabio Estevam
     

02 Jun, 2014

1 commit


28 May, 2014

1 commit


28 Apr, 2014

1 commit

  • Enable CONFIG_SYS_GENERIC_BOARD, so that we get rid of the following warning on
    boot:

    "Warning: Your board does not use generic board. Please read
    doc/README.generic-board and take action. Boards not
    upgraded by the late 2014 may break or be removed."

    Signed-off-by: Fabio Estevam

    Fabio Estevam
     

04 Apr, 2014

1 commit


01 Apr, 2014

2 commits

  • The DRAM size can be easily detected at runtime on i.MX53. Implement
    such detection on MX53QSB and adjust the rest of the macros accordingly
    to use the detected values.

    An important thing to note here is that we had to override the function
    for trimming the effective DRAM address, get_effective_memsize(). That
    is because the function uses CONFIG_MAX_MEM_MAPPED as the upper bound of
    the available DRAM and we don't have gd->bd->bi_dram[0].size set up at
    the time the function is called, thus we cannot put this into the macro
    CONFIG_MAX_MEM_MAPPED . Instead, we use custom override where we use the
    size of the first DRAM block which we just detected.

    Signed-off-by: Marek Vasut
    Cc: Fabio Estevam
    Cc: Stefano Babic
    Cc: Wolfgang Denk

    Marek Vasut
     
  • Fix memory access slowness on i.MX53 MX53QSB board. Let us inspect the
    issue: First of all, the i.MX53 CPU has two memory banks mapped at
    0x7000_0000 and 0xb000_0000 and each of those can hold up to 1GiB of
    DRAM memory. Notice that the memory area is not continuous. On MX53QSB,
    each of the banks contain 512MiB of DRAM, which makes a total of 1GiB
    of memory available to the system.

    The problem is how the relocation of U-Boot is treated on i.MX53 . The
    U-Boot is placed at the ((start of first DRAM partition) + (gd->ram_size)) .
    This in turn poses a problem, since in our case, the gd->ram_size is 1GiB,
    the first DRAM bank starts at 0x7000_0000 and contains 512MiB of memory.
    Thus, with this algorithm, U-Boot is placed at offset:

    0x7000_0000 + 1GiB - sizeof(u-boot and some small margin)

    This is past the DRAM available in the first bank on MX53QSB, but is still
    within the address range of the first DRAM bank. Because of the memory
    wrap-around, the data can still be read and written to this area, but the
    access is much slower.

    There were two ideas how to solve this problem, first was to map both of
    the available DRAM chunks next to one another by using MMU, second was to
    define CONFIG_VERY_BIG_RAM and CONFIG_MAX_MEM_MAPPED to size of the memory
    in the first DRAM bank. We choose the later because it turns out the former
    is not applicable afterall. The former cannot be used in case Linux kernel
    was loaded into the second DRAM bank area, which would be remapped and one
    would try booting the kernel, since at some point before the kernel is started,
    the MMU would be turned off, which would destroy the mapping and hang the
    system.

    Signed-off-by: Marek Vasut
    Cc: Fabio Estevam
    Cc: Stefano Babic
    Cc: Wolfgang Denk

    Marek Vasut
     

13 Mar, 2014

1 commit


11 Feb, 2014

1 commit


18 Dec, 2013

1 commit

  • According to the README:

    "- CONFIG_SYS_SPD_BUS_NUM
    If SPD EEPROM is on an I2C bus other than the first
    one, specify here. Note that the value must resolve
    to something your driver can deal with."

    There is no SPD EEPROM on the imx boards, so ged rid of this option.

    Signed-off-by: Fabio Estevam
    Acked-by: Stefano Babic

    Fabio Estevam
     

13 Nov, 2013

1 commit


05 Nov, 2013

1 commit


17 Oct, 2013

1 commit


15 Oct, 2013

1 commit


24 Jul, 2013

1 commit


12 Jul, 2013

1 commit


13 Jan, 2013

1 commit

  • The CONFIG_SYS_CBSIZE has been change to 512 to avoid runtime errors as:

    ,---[ Runtime error ]
    | Hit any key to stop autoboot: 0
    | MX53LOCO U-Boot > pri netboot
    | netboot=echo Booting from net ...; run netargs; if test ...
    | prefetch abort
    | pc : [] lr : []
    | sp : af566e20 ip : 00000000 fp : 00000000
    | r10: 00000002 r9 : af6dfc28 r8 : af566f58
    | r7 : af6dfc10 r6 : 00000001 r5 : 00000002 r4 : 74206669
    | r3 : 00000000 r2 : 00000060 r1 : 00000020 r0 : 0000018e
    | Flags: nZCv IRQs off FIQs off Mode SVC_32
    | Resetting CPU ...
    |
    | resetting ...
    `---

    Signed-off-by: Otavio Salvador

    Otavio Salvador
     

27 Dec, 2012

1 commit

  • Since commit c733681 (pmic: Extend PMIC framework to support multiple instances
    of PMIC devices) mx53loco fails to allocate the memory for PMIC:

    U-Boot 2013.01-rc2-dirty (Dec 20 2012 - 15:55:01)

    Board: MX53 LOCO
    I2C: ready
    DRAM: 1 GiB
    pmic_alloc: No available memory for allocation!
    pmic_init: POWER allocation error!
    CPU: Freescale i.MX53 family rev2.0 at 800 MHz
    Reset cause: POR
    MMC: FSL_SDHC: 0, FSL_SDHC: 1

    Calling the PMIC related functions at a later stage, ie, from board_late_init()
    fixes the issue.

    Reported-by: Robert Nelson
    Signed-off-by: Fabio Estevam
    Tested-by: Stefano Babic

    Fabio Estevam
     

26 Dec, 2012

2 commits


08 Dec, 2012

1 commit

  • Conflicts:
    drivers/power/power_fsl.c
    include/configs/mx35pdk.h
    include/configs/mx53loco.h
    include/configs/woodburn_common.h
    board/woodburn/woodburn.c

    These boards still use the old old PMIC framework, so they
    do not merge properly after the power framework was merged into
    mainline.

    Fix all conflicts and update woodburn to use Power Framework.

    Signed-off-by: Stefano Babic

    Stefano Babic
     

19 Nov, 2012

1 commit


14 Nov, 2012

2 commits


10 Nov, 2012

1 commit


27 Oct, 2012

1 commit


26 Oct, 2012

2 commits


23 Oct, 2012

1 commit


18 Oct, 2012

2 commits


16 Oct, 2012

1 commit


01 Sep, 2012

2 commits


10 Aug, 2012

1 commit


18 Jul, 2012

1 commit

  • * 'next' of git://git.denx.de/u-boot-video:
    ipu_common: Add ldb_clk for use in parenting the pixel clock
    ipu_common: Do not hardcode the ipu_clk frequency
    ipu_common: Rename MXC_CCM_BASE
    ipu_common: Let clk_ipu_enable/disable only run on MX51 and MX53
    ipu_common: Only apply the erratum to MX51
    video: Rename CONFIG_VIDEO_MX5
    mx6: Allow mx6 to access the IPUv3 registers
    common lcd: minor coding style changes

    Signed-off-by: Wolfgang Denk

    Wolfgang Denk