08 Apr, 2014

4 commits


07 Apr, 2014

5 commits


04 Apr, 2014

3 commits

  • This patch adds the groundwork for generating signed BootStream, which
    can be used by the HAB library in i.MX28. We are adding a new target,
    u-boot-signed.sb , since the process for generating regular non-signed
    BootStream is much easier. Moreover, the signed bootstream depends on
    external _proprietary_ _binary-only_ tool from Freescale called 'cst',
    which is available only under NDA.

    To make things even uglier, the CST or HAB mandates a kind-of circular
    dependency. The problem is, unlike the regular IVT, which is generated
    by mxsimage, the IVT for signed boot must be generated by hand here due
    to special demands of the CST. The U-Boot binary (or SPL binary) and IVT
    are then signed by the CST as a one block. But here is the problem. The
    size of the entire image (U-Boot, IVT, CST blocks) must be appended at
    the end of IVT. But the size of the entire image is not known until the
    CST has finished signing the U-Boot and IVT. We solve this by expecting
    the CST block to be always 3904B (which it is in case two files, U-Boot
    and the hand-made IVT, are signed in the CST block).

    Signed-off-by: Marek Vasut
    Cc: Stefano Babic

    Marek Vasut
     
  • Conflicts:
    arch/arm/cpu/arm926ejs/mxs/mxsimage.mx23.cfg
    arch/arm/cpu/arm926ejs/mxs/mxsimage.mx28.cfg

    Signed-off-by: Stefano Babic

    Stefano Babic
     
  • This reverts commit 53e6b14e037c9f72e6d03244c32d8d597e2e0234.

    Patch does not merge anymore with u-boot-arm and must be rebased.

    Signed-off-by: Stefano Babic

    Stefano Babic
     

02 Apr, 2014

5 commits


01 Apr, 2014

13 commits

  • Add support for serial console into the i.MX23/i.MX28 SPL. A full,
    uncrippled serial console support comes very helpful when debugging
    various spectacular hardware bringup issues early in the process.
    Because we do not use SPL framework, but have our own minimalistic
    SPL, which is compatible with the i.MX23/i.MX28 BootROM, we do not
    use preloader_console_init(), but instead use a similar function to
    start the console. Nonetheless, to avoid blowing up the size of the
    SPL binary, this support is enabled only if CONFIG_SPL_SERIAL_SUPPORT
    is defined, which is disabled by default.

    Signed-off-by: Marek Vasut
    Cc: Stefano Babic

    Marek Vasut
     
  • Set the GD pointer in the SPL to a defined symbol so various
    functions from U-Boot can be used without adverse side effects.

    Signed-off-by: Marek Vasut
    Cc: Stefano Babic

    Marek Vasut
     
  • The DRAM size can be easily detected at runtime on i.MX53. Implement
    such detection on M53EVK 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 M53EVK 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 M53EVK,
    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 M53EVK, 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
     
  • 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
     
  • Add support for PCIe on MX6 SabreSDP board and enable the support
    in the config file.

    Signed-off-by: Marek Vasut
    Cc: Stefano Babic
    Cc: Fabio Estevam
    Cc: Liu Ying

    Marek Vasut
     
  • Implement a callback to toggle the slot power supply. The callback
    can be overriden in case some more complex power supply for the slot
    was implemented in hardware, yet for the usual case, one can define
    a GPIO which toggles the power to the slot.

    Signed-off-by: Marek Vasut
    Cc: Stefano Babic
    Cc: Fabio Estevam
    Cc: Liu Ying

    Marek Vasut
     
  • Use of PCIe on SABRE Lite and Nitrogen6x boards
    is atypical and requires the use of custom daughter
    boards.

    Use in U-Boot is even rarer, so this patch removes it from
    the standard configuration.

    Signed-off-by: Eric Nelson
    Acked-by: Marek Vasut

    Eric Nelson
     
  • CONFIG_BOOT_INTERNAL is not used anywhere, so let's remove it.

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

    Fabio Estevam
     
  • Add yet another OCOTP driver for this i.MX family. This time, it's a driver for
    the OCOTP variant found in the i.MX23 and i.MX28. This version of OCOTP is too
    different from the i.MX6 one that I could not use the mxc_ocotp.c driver without
    making it into a big pile of #ifdef . This driver implements the regular fuse
    command interface, but due to the IP blocks' limitation, we support only READ
    and PROG functions.

    Signed-off-by: Marek Vasut
    Cc: Stefano Babic

    Marek Vasut
     
  • This patch adds the groundwork for generating signed BootStream, which
    can be used by the HAB library in i.MX28. We are adding a new target,
    u-boot-signed.sb , since the process for generating regular non-signed
    BootStream is much easier. Moreover, the signed bootstream depends on
    external _proprietary_ _binary-only_ tool from Freescale called 'cst',
    which is available only under NDA.

    To make things even uglier, the CST or HAB mandates a kind-of circular
    dependency. The problem is, unlike the regular IVT, which is generated
    by mxsimage, the IVT for signed boot must be generated by hand here due
    to special demands of the CST. The U-Boot binary (or SPL binary) and IVT
    are then signed by the CST as a one block. But here is the problem. The
    size of the entire image (U-Boot, IVT, CST blocks) must be appended at
    the end of IVT. But the size of the entire image is not known until the
    CST has finished signing the U-Boot and IVT. We solve this by expecting
    the CST block to be always 3904B (which it is in case two files, U-Boot
    and the hand-made IVT, are signed in the CST block).

    Signed-off-by: Marek Vasut
    Cc: Stefano Babic

    Marek Vasut
     
  • When using HAB, there are additional special requirements on the placement of
    U-Boot and the U-Boot SPL in memory. To fullfill these, this patch moves the
    U-Boot binary a little further from the begining of the DRAM, so the HAB CST
    and IVT can be placed in front of the U-Boot binary. This is necessary, since
    both the U-Boot and the IVT must be contained in single CST signature. To
    make things worse, the IVT must be concatenated with one more entry at it's
    end, that is the length of the entire CST signature, IVT and U-Boot binary
    in memory. By placing the blocks in this order -- CST, IVT, U-Boot, we can
    easily align them all and then produce the length field as needed.

    As for the SPL, on i.MX23/i.MX28, the SPL size is limited to 32 KiB, thus
    we place the IVT at 0x8000 offset, CST right past IVT and claim the size
    is correct. The HAB library accepts this setup.

    Finally, to make sure the vectoring in SPL still works even after moving
    the SPL from 0x0 to 0x1000, we add a small function which copies the
    vectoring code and tables to 0x0. This is fine, since the vectoring code
    is position independent.

    Signed-off-by: Marek Vasut
    Cc: Stefano Babic

    Marek Vasut
     

31 Mar, 2014

1 commit


27 Mar, 2014

1 commit

  • I2C protocol requires open-drain IOs. Fix the Dalmore and Venice2 pinmux
    tables to configure the IOs correctly. Without this, Tegra may actively
    drive the lines high while an external device is actively driving the
    lines low, which can only lead to bad things.

    Signed-off-by: Stephen Warren
    Acked-by: Simon Glass
    Signed-off-by: Tom Warren

    Stephen Warren
     

25 Mar, 2014

1 commit


18 Mar, 2014

7 commits

  • Enable the Chrome OS EC emulation for sandbox along with LCD, sound
    expanded GPIOs and a few other options to make this work correctly.

    Reviewed-by: Simon Glass
    Tested-by: Che-Liang Chiou
    Signed-off-by: Simon Glass

    Simon Glass
     
  • This function is needed when CONFIG_OF_SPI is defined.

    Signed-off-by: Simon Glass

    Simon Glass
     
  • When jumping from one sandbox U-Boot to another in sandbox, the RAM buffer
    is preserved in the jump by using a temporary file. Add an option to tell
    the receiving U-Boot to remove this file when it is no longer needed.

    Similarly the old U-Boot image is left behind in this case. We cannot delete
    it immediately since gdb cannot then find its debug symbols. Delete it just
    before exiting.

    Together these changes ensure that temporary files are removed both for
    memory and U-Boot.

    Signed-off-by: Simon Glass

    Simon Glass
     
  • It is useful for Cltl-C to be handled by U-Boot as it is on other boards.
    But it is also useful to be able to terminate U-Boot with Ctrl-C.

    Add an option to enable signals while in raw mode, and make this the
    default. Add an option to leave the terminal cooked, which is useful for
    redirecting output.

    Signed-off-by: Simon Glass

    Simon Glass
     
  • Unfortunately SDL requires getenv() to operate, since it wants to figure out
    the display type. U-Boot has its own getenv() and they conflict. As a
    work-around use #define to resolve the conflict.

    A better but more complex solution might be to rename some U-Boot symbols
    at link time. SDL audio is not functional at present, likely due to a related
    issue.

    Note: Vic Yank wrote a script for this, filed in crbug.com/271125.

    Reviewed-by: Simon Glass
    Signed-off-by: Simon Glass

    Simon Glass
     
  • The i2s code is in fact Samsung-specific, but there might be other
    implementation. Move this code into its own file. This makes it slightly
    more obviously how to adjust the code to support another SoC, when someone
    takes this task on.

    Also drop non-FDT support, since it isn't used on Exynos 5.

    Tested-by: Che-Liang Chiou
    Signed-off-by: Simon Glass

    Simon Glass
     
  • Add a simple LCD driver which uses SDL to display the image. We update the
    image regularly, while still providing for reasonable performance.

    Adjust the common lcd code to support sandbox.

    For command-line runs we do not want the LCD to be displayed, so add a
    --show_lcd option to enable it.

    Tested-by: Che-Liang Chiou
    Signed-off-by: Simon Glass

    Simon Glass