Skip to content
Snippets Groups Projects
  1. Dec 15, 2009
  2. Dec 14, 2009
  3. Dec 11, 2009
  4. Dec 09, 2009
    • Peter Korsgaard's avatar
      mpc83xx: boot time regression, move LCRR setup back to cpu_init_f · 3b887ca8
      Peter Korsgaard authored
      
      Commit c7190f02 (retain POR values of non-configured ACR, SPCR, SCCR,
      and LCRR bitfields) moved the LCRR assignment to after relocation
      to RAM because of the potential problem with changing the local bus
      clock while executing from flash.
      
      This change unfortunately adversely affects the boot time, as running
      all code up to cpu_init_r can cause significant slowdown.
      
      E.G. on a 8347 board a bootup time increase of ~600ms has been observed:
      
         0.020 CPU:   e300c1, MPC8347_PBGA_EA, Rev: 3.0 at 400 MHz, CSB: 266.667 MHz
         0.168 RS:    232
         0.172 I2C:   ready
         0.176 DRAM:  64 MB
         1.236 FLASH: 32 MB
      
      Versus:
      
         0.016 CPU:   e300c1, MPC8347_PBGA_EA, Rev: 3.0 at 400 MHz, CSB: 266.667 MHz
         0.092 RS:    232
         0.092 I2C:   ready
         0.096 DRAM:  64 MB
         0.644 FLASH: 32 MB
      
      So far no boards have needed the late LCRR setup, so simply revert it
      for now - If it is needed at a later time, those boards can either do
      their own final LCRR setup in board code (E.G. in board_early_init_r),
      or we can introduce a CONFIG_SYS_LCRR_LATE config option to only do
      the setup in cpu_init_r.
      
      Signed-off-by: default avatarPeter Korsgaard <jacmet@sunsite.dk>
      Signed-off-by: default avatarKim Phillips <kim.phillips@freescale.com>
      3b887ca8
  5. Dec 08, 2009
  6. Dec 07, 2009
  7. Dec 05, 2009
    • Wolfgang Denk's avatar
      Fix out-of-tree building of "apollon" board. · 8cbf4e4f
      Wolfgang Denk authored
      
      Signed-off-by: default avatarWolfgang Denk <wd@denx.de>
      8cbf4e4f
    • Mike Frysinger's avatar
      lzma: ignore unset filesizes · f68ab43d
      Mike Frysinger authored
      
      The Linux kernel build system changed how it compresses things with LZMA
      such that the header no longer contains the filesize (it is instead set to
      all F's).  So if we get a LZMA image that has -1 for the 64bit field,
      let's just assume that the decompressed size is unknown and continue on.
      
      Signed-off-by: default avatarMike Frysinger <vapier@gentoo.org>
      f68ab43d
    • Detlev Zundel's avatar
      README: Rearrange paragraphs to regain linear arrangement. · cccfc2ab
      Detlev Zundel authored
      
      Two later additions to the Configuration Option section unfortunately
      split the description of Show boot progress and the list of its call outs.
      
      Signed-off-by: default avatarDetlev Zundel <dzu@denx.de>
      cccfc2ab
    • Peter Tyser's avatar
      tools/mkimage: Print FIT image contents after creation · c81296c1
      Peter Tyser authored
      
      Previously, there was no indication to the user that a FIT image was
      successfully created after executing mkimage.  For example:
      
        $ mkimage -f uImage.its uImage.itb
        DTC: dts->dtb  on file "uImage.its"
      
      Adding some additional output after creating a FIT image lets the user
      know exactly what is contained in their image, eg:
      
        $ mkimage -f uImage.its uImage.itb
        DTC: dts->dtb  on file "uImage.its"
        FIT description: Linux kernel 2.6.32-rc7-00201-g7550d6f-dirty
        Created:         Tue Nov 24 15:43:01 2009
         Image 0 (kernel@1)
          Description:  Linux Kernel 2.6.32-rc7-00201-g7550d6f-dirty
          Type:         Kernel Image
          Compression:  gzip compressed
          Data Size:    2707311 Bytes = 2643.86 kB = 2.58 MB
          Architecture: PowerPC
          OS:           Linux
          Load Address: 0x00000000
          Entry Point:  0x00000000
          Hash algo:    crc32
          Hash value:   efe0798b
          Hash algo:    sha1
          Hash value:   ecafba8c95684f2c8fec67e33c41ec88df1534d7
         Image 1 (fdt@1)
          Description:  Flattened Device Tree blob
          Type:         Flat Device Tree
          Compression:  uncompressed
          Data Size:    12288 Bytes = 12.00 kB = 0.01 MB
          Architecture: PowerPC
          Hash algo:    crc32
          Hash value:   a5cab676
          Hash algo:    sha1
          Hash value:   168722b13e305283cfd6603dfe8248cc329adea6
         Default Configuration: 'config@1'
         Configuration 0 (config@1)
          Description:  Default Linux kernel
          Kernel:       kernel@1
          FDT:          fdt@1
      
      This brings the behavior of creating a FIT image in line with creating a
      standard uImage, which also prints out the uImage contents after
      creation.
      
      Signed-off-by: default avatarPeter Tyser <ptyser@xes-inc.com>
      c81296c1
    • Peter Tyser's avatar
      tools/fit_image.c: Remove unused fit_set_header() · 8e1c8966
      Peter Tyser authored
      
      The FIT fit_set_header() function was copied from the standard uImage's
      image_set_header() function during mkimage reorganization.  However, the
      fit_set_header() function is not used since FIT images use a standard
      device tree blob header.
      
      Signed-off-by: default avatarPeter Tyser <ptyser@xes-inc.com>
      8e1c8966
    • Peter Tyser's avatar
      tools/mkimage: Assume FDT image type for FIT images · 1a99de2c
      Peter Tyser authored
      
      When building a Flattened Image Tree (FIT) the image type needs to be
      "flat_dt".  Commit 89a4d6b1 introduced a
      regression which caused the user to need to specify the "-T flat_dt"
      parameter on the command line when building a FIT image.  The "-T
      flat_dt" parameter should not be needed and is at odds with the current
      FIT image documentation.
      
      Signed-off-by: default avatarPeter Tyser <ptyser@xes-inc.com>
      1a99de2c
  8. Dec 04, 2009
  9. Dec 02, 2009
Loading