1. 07 Apr, 2014 1 commit
  2. 04 Apr, 2014 3 commits
    • Marek Vasut's avatar
      arm: mxs: Add support for generating signed BootStream · 1a9df13d
      Marek Vasut authored and Stefano Babic's avatar Stefano Babic committed
      
      
      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's avatarMarek Vasut <marex@denx.de>
      Cc: Stefano Babic <sbabic@denx.de>
      1a9df13d
    • Stefano Babic's avatar
      Merge branch 'master' of git://git.denx.de/u-boot-arm into master · 1cad23c5
      Stefano Babic authored
      
      
      Conflicts:
      	arch/arm/cpu/arm926ejs/mxs/mxsimage.mx23.cfg
      	arch/arm/cpu/arm926ejs/mxs/mxsimage.mx28.cfg
      Signed-off-by: Stefano Babic's avatarStefano Babic <sbabic@denx.de>
      1cad23c5
    • Stefano Babic's avatar
      Revert "arm: mxs: Add support for generating signed BootStream" · 5dd73bc0
      Stefano Babic authored
      This reverts commit 53e6b14e
      
      .
      
      Patch does not merge anymore with u-boot-arm and must be rebased.
      Signed-off-by: Stefano Babic's avatarStefano Babic <sbabic@denx.de>
      5dd73bc0
  3. 02 Apr, 2014 5 commits
  4. 01 Apr, 2014 2 commits
    • Marek Vasut's avatar
      arm: mxs: Add serial console support into SPL · 9926eb31
      Marek Vasut authored and Stefano Babic's avatar Stefano Babic committed
      
      
      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's avatarMarek Vasut <marex@denx.de>
      Cc: Stefano Babic <sbabic@denx.de>
      9926eb31
    • Marek Vasut's avatar
      arm: mxs: Properly set GD pointer in SPL · 65ed5e85
      Marek Vasut authored and Stefano Babic's avatar Stefano Babic committed
      
      
      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's avatarMarek Vasut <marex@denx.de>
      Cc: Stefano Babic <sbabic@denx.de>
      65ed5e85
  5. 31 Mar, 2014 12 commits
    • Marek Vasut's avatar
      arm: mx5: Avoid hardcoding memory sizes on M53EVK · 97334c66
      Marek Vasut authored and Stefano Babic's avatar Stefano Babic committed
      
      
      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's avatarMarek Vasut <marex@denx.de>
      Cc: Fabio Estevam <fabio.estevam@freescale.com>
      Cc: Stefano Babic <sbabic@denx.de>
      Cc: Wolfgang Denk <wd@denx.de>
      97334c66
    • Marek Vasut's avatar
      arm: mx5: Fix memory slowness on M53EVK · 2f844e76
      Marek Vasut authored and Stefano Babic's avatar Stefano Babic committed
      
      
      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's avatarMarek Vasut <marex@denx.de>
      Cc: Fabio Estevam <fabio.estevam@freescale.com>
      Cc: Stefano Babic <sbabic@denx.de>
      Cc: Wolfgang Denk <wd@denx.de>
      2f844e76
    • Marek Vasut's avatar
      arm: mx5: Avoid hardcoding memory sizes on MX53QSB · 31c832f9
      Marek Vasut authored and Stefano Babic's avatar Stefano Babic committed
      
      
      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's avatarMarek Vasut <marex@denx.de>
      Cc: Fabio Estevam <fabio.estevam@freescale.com>
      Cc: Stefano Babic <sbabic@denx.de>
      Cc: Wolfgang Denk <wd@denx.de>
      31c832f9
    • Marek Vasut's avatar
      arm: mx5: Fix memory slowness on MX53QSB · f79a023f
      Marek Vasut authored and Stefano Babic's avatar Stefano Babic committed
      
      
      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's avatarMarek Vasut <marex@denx.de>
      Cc: Fabio Estevam <fabio.estevam@freescale.com>
      Cc: Stefano Babic <sbabic@denx.de>
      Cc: Wolfgang Denk <wd@denx.de>
      f79a023f
    • Marek Vasut's avatar
      ARM: mx6: Add PCIe on SabreSDP · e919aa23
      Marek Vasut authored and Stefano Babic's avatar Stefano Babic committed
      
      
      Add support for PCIe on MX6 SabreSDP board and enable the support
      in the config file.
      Signed-off-by: Marek Vasut's avatarMarek Vasut <marex@denx.de>
      Cc: Stefano Babic <sbabic@denx.de>
      Cc: Fabio Estevam <fabio.estevam@freescale.com>
      Cc: Liu Ying <Ying.Liu@freescale.com>
      e919aa23
    • Marek Vasut's avatar
      pci: mx6: Implement power callback · a778aeae
      Marek Vasut authored and Stefano Babic's avatar Stefano Babic committed
      
      
      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's avatarMarek Vasut <marex@denx.de>
      Cc: Stefano Babic <sbabic@denx.de>
      Cc: Fabio Estevam <fabio.estevam@freescale.com>
      Cc: Liu Ying <Ying.Liu@freescale.com>
      a778aeae
    • Eric Nelson's avatar
      ARM: mx6: Disable PCIe on SABRE Lite/Nitrogen6x · ed2f0e1f
      Eric Nelson authored and Stefano Babic's avatar Stefano Babic committed
      
      
      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: default avatarEric Nelson <eric.nelson@boundarydevices.com>
      Acked-by: Marek Vasut's avatarMarek Vasut <marex@denx.de>
      ed2f0e1f
    • Fabio Estevam's avatar
      woodburn_sd: Remove CONFIG_BOOT_INTERNAL · 3e94380b
      Fabio Estevam authored and Stefano Babic's avatar Stefano Babic committed
      
      
      CONFIG_BOOT_INTERNAL is not used anywhere, so let's remove it.
      Signed-off-by: default avatarFabio Estevam <fabio.estevam@freescale.com>
      Acked-by: Stefano Babic's avatarStefano Babic <sbabic@denx.de>
      3e94380b
    • Marek Vasut's avatar
      ARM: mxs: Add OCOTP driver · 2bbcccf5
      Marek Vasut authored and Stefano Babic's avatar Stefano Babic committed
      
      
      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's avatarMarek Vasut <marex@denx.de>
      Cc: Stefano Babic <sbabic@denx.de>
      2bbcccf5
    • Marek Vasut's avatar
      arm: mxs: Add support for generating signed BootStream · 53e6b14e
      Marek Vasut authored and Stefano Babic's avatar Stefano Babic committed
      
      
      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's avatarMarek Vasut <marex@denx.de>
      Cc: Stefano Babic <sbabic@denx.de>
      53e6b14e
    • Marek Vasut's avatar
      arm: mxs: Adjust the load address of U-Boot and SPL for HAB · 9c2c8a31
      Marek Vasut authored and Stefano Babic's avatar Stefano Babic committed
      
      
      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's avatarMarek Vasut <marex@denx.de>
      Cc: Stefano Babic <sbabic@denx.de>
      9c2c8a31
    • Hannes Petermaier's avatar
      board: enable 32kHz RTC OSC at B&R boards · 96de041e
      Hannes Petermaier authored
      
      
      Since RTC-Clock is needed on all B&R boards, the OSC will be enabled
      wihtin SPL-stage.
      Signed-off-by: default avatarHannes Petermaier <oe5hpm@oevsv.at>
      96de041e
  6. 26 Mar, 2014 1 commit
  7. 25 Mar, 2014 1 commit
  8. 18 Mar, 2014 15 commits