Skip to content
Snippets Groups Projects
  1. Jun 04, 2013
  2. May 14, 2013
  3. Mar 27, 2013
  4. Mar 01, 2013
  5. Feb 08, 2013
  6. Dec 13, 2012
  7. Nov 13, 2012
    • Gabe Black's avatar
      fdt: Add option to default to most compatible conf in a fit image · d95f6ec7
      Gabe Black authored
      
      When booting a fit image with multiple configurations, the user either has to
      specify which configuration to use explicitly, or there has to be a default
      defined which is chosen automatically. This change adds an option to change
      that behavior so that a configuration can be selected explicitly, or the
      configuration which has the device tree that claims to be compatible with the
      earliest item in U-Boot's device tree.
      
      In other words, if U-Boot claimed to be compatible with A, B, and then C, and
      the configurations claimed to be compatible with A, D and B, D and D, E, the
      first configuration, A, D, would be chosen. Both the first and second
      configurations match, but the first one matches a more specific entry in
      U-Boot's device tree. The order in the kernel's device tree is ignored.
      
      Signed-off-by: default avatarGabe Black <gabeblack@google.com>
      
      Commit-Ready: Gabe Black <gabeblack@chromium.org>
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
      d95f6ec7
  8. Nov 04, 2012
    • Kim Phillips's avatar
      common/misc: sparse fixes · 199adb60
      Kim Phillips authored
      
      command.c:44:38: error: bad constant expression
      dlmalloc.c:1468:2: warning: Using plain integer as NULL pointer
      dlmalloc.c:1468:5: warning: Using plain integer as NULL pointer
      dlmalloc.c:2176:12: warning: Using plain integer as NULL pointer
      dlmalloc.c:2179:31: warning: Using plain integer as NULL pointer
      dlmalloc.c:2382:14: warning: Using plain integer as NULL pointer
      dlmalloc.c:2436:14: warning: Using plain integer as NULL pointer
      dlmalloc.c:2582:31: warning: Using plain integer as NULL pointer
      dlmalloc.c:2585:17: warning: Using plain integer as NULL pointer
      dlmalloc.c:2646:14: warning: Using plain integer as NULL pointer
      dlmalloc.c:2659:19: warning: Using plain integer as NULL pointer
      dlmalloc.c:2692:19: warning: Using plain integer as NULL pointer
      dlmalloc.c:2707:19: warning: Using plain integer as NULL pointer
      dlmalloc.c:2708:14: warning: Using plain integer as NULL pointer
      dlmalloc.c:2786:31: warning: Using plain integer as NULL pointer
      dlmalloc.c:2801:12: warning: Using plain integer as NULL pointer
      dlmalloc.c:2801:22: warning: Using plain integer as NULL pointer
      dlmalloc.c:2926:27: warning: Using plain integer as NULL pointer
      dlmalloc.c:2928:14: warning: Using plain integer as NULL pointer
      dlmalloc.c:2929:12: warning: Using plain integer as NULL pointer
      dlmalloc.c:3075:14: warning: Using plain integer as NULL pointer
      hush.c:292:14: warning: symbol 'last_return_code' was not declared. Should it be static?
      hush.c:293:5: warning: symbol 'nesting_level' was not declared. Should it be static?
      hush.c:2175:20: warning: Using plain integer as NULL pointer
      hush.c:2175:34: warning: Using plain integer as NULL pointer
      hush.c:2210:41: warning: Using plain integer as NULL pointer
      hush.c:2216:45: warning: Using plain integer as NULL pointer
      hush.c:2249:25: warning: Using plain integer as NULL pointer
      hush.c:2332:13: warning: symbol 'new_pipe' was not declared. Should it be static?
      hush.c:2390:5: warning: symbol 'reserved_word' was not declared. Should it be static?
      hush.c:2927:5: warning: symbol 'parse_stream' was not declared. Should it be static?
      hush.c:3127:6: warning: symbol 'mapset' was not declared. Should it be static?
      hush.c:3133:6: warning: symbol 'update_ifs_map' was not declared. Should it be static?
      hush.c:3161:5: warning: symbol 'parse_stream_outer' was not declared. Should it be static?
      hush.c:3295:34: warning: Using plain integer as NULL pointer
      hush.c:3631:5: warning: symbol 'do_showvar' was not declared. Should it be static
      image.c:1282:29: warning: Using plain integer as NULL pointer
      image.c:1315:41: warning: Using plain integer as NULL pointer
      image.c:1330:25: warning: Using plain integer as NULL pointer
      image.c:1706:25: warning: Using plain integer as NULL pointer
      main.c:510:10: warning: symbol 'hist_num' was not declared. Should it be static?
      main.c:512:5: warning: symbol 'hist_list' was not declared. Should it be static?
      main.c:513:6: warning: symbol 'hist_lines' was not declared. Should it be static?
      usb_storage.c:195:6: warning: symbol 'usb_show_progress' was not declared. Should it be static?
      usb_storage.c:440:48: warning: Using plain integer as NULL pointer
      usb_storage.c:503:5: warning: symbol 'usb_stor_BBB_comdat' was not declared. Should it be static?
      usb_storage.c:551:5: warning: symbol 'usb_stor_CB_comdat' was not declared. Should it be static?
      usb_storage.c:629:55: warning: Using plain integer as NULL pointer
      usb_storage.c:620:5: warning: symbol 'usb_stor_CBI_get_status' was not declared. Should it be static?
      usb_storage.c:675:43: warning: Using plain integer as NULL pointer
      usb_storage.c:668:5: warning: symbol 'usb_stor_BBB_clear_endpt_stall' was not declared. Should it be static?
      usb_storage.c:679:5: warning: symbol 'usb_stor_BBB_transport' was not declared. Should it be static?
      usb_storage.c:801:5: warning: symbol 'usb_stor_CB_transport' was not declared. Sh
      xyzModem.c:104:1: warning: symbol 'CYGACC_COMM_IF_GETC_TIMEOUT' was not declared. Should it be static?
      xyzModem.c:122:1: warning: symbol 'CYGACC_COMM_IF_PUTC' was not declared. Should it be static?
      xyzModem.c:169:1: warning: symbol 'parse_num' was not declared. Should it be stat
      
      note: hush.c's nesting_level deleted because not used.
      
      Signed-off-by: default avatarKim Phillips <kim.phillips@freescale.com>
      199adb60
  9. Oct 15, 2012
  10. Sep 02, 2012
  11. Aug 23, 2012
  12. Apr 30, 2012
  13. Mar 30, 2012
  14. Mar 18, 2012
  15. Mar 06, 2012
    • Stephen Warren's avatar
      image: Support FDTs already loaded at their load address · e37ae40e
      Stephen Warren authored
      
      boot_get_fdt() expects a uImage-wrapped FDT to be loaded to a staging
      location, and then memmove()s it to the load address specified in the
      header. This change enhances boot_get_fdt() to detect when the image has
      already been loaded to the correct address, and skip this memmove(). The
      detection algorithm was written to match the equivalent for the kernel;
      see bootm_load_os()'s IH_COMP_NONE case.
      
      v2: New patch
      
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      e37ae40e
  16. Feb 27, 2012
    • Shawn Guo's avatar
      common/image.c: align usage of fdt_high with initrd_high · fa34f6b2
      Shawn Guo authored
      
      The commit message of a28afca5 (Add uboot "fdt_high" enviroment variable)
      states that fdt_high behaves similarly to the existing initrd_high.
      But fdt_high actually has an outstanding difference from initrd_high.
      The former specifies the start address, while the later specifies the
      end address.
      
      As fdt_high and initrd_high will likely be used together, it'd be nice
      to have them behave same.  The patch changes the behavior of fdt_high
      to have it aligned with initrd_high.
      
      The document of fdt_high in README is updated with an example to
      demonstrate the usage of this environment variable.
      
      Signed-off-by: default avatarShawn Guo <shawn.guo@linaro.org>
      Acked-by: default avatarSimon Glass <sjg@chromium.org>
      fa34f6b2
  17. Jan 13, 2012
  18. Dec 12, 2011
    • Kumar Gala's avatar
      powerpc/bootm: Flush ramdisk and device tree image when booting on MP · 3b200110
      Kumar Gala authored
      
      We already flush the kernel image after we've loaded it to ensure
      visiblity to the other cores.  We need to do the same thing for the
      ramdisk and device tree images.  In AMP boot scenarios we might not be
      HW cache coherent with the secondary core that we are loading and
      setting the ramdisk and device tree up for.  Thus we need to ensure
      we've flushed the regions of memory utilized by ramdisk and device tree
      so the loadding and any modifications (from decompression or fdt updates)
      are made visible to the secondary cores.
      
      Signed-off-by: default avatarKumar Gala <galak@kernel.crashing.org>
      3b200110
  19. Dec 01, 2011
    • Stephen Warren's avatar
      image: Implement IH_TYPE_KERNEL_NOLOAD · b9b50e89
      Stephen Warren authored
      
      The legacy uImage format includes an absolute load and entry-point
      address. When bootm operates on a kernel uImage in memory that isn't
      loaded at the address in the image's load address, U-Boot will copy
      the image to its address in the header.
      
      Some kernel images can actually be loaded and used at any arbitrary
      address. An example is an ARM Linux kernel zImage file. To represent
      this capability, IH_TYPE_KERNEL_NOLOAD is implemented, which operates
      just like IH_TYPE_KERNEL, except that the load address header is
      ignored, and U-Boot does not copy the image to its load address, but
      rather uses it in-place.
      
      This is useful when sharing a single (uImage-wrapped) zImage across
      multiple boards with different memory layouts; in this case, a specific
      load address need not be picked when creating the uImage, but instead
      is selected by the board-specific U-Boot environment used to load and
      boot that image.
      
      v2: Rename from IH_TYPE_KERNEL_ANYLOAD to IH_TYPE_KERNEL_NOLOAD.
      
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      Signed-off-by: default avatarStefan Roese <sr@denx.de>
      b9b50e89
  20. Oct 23, 2011
    • Stefano Babic's avatar
      mkimage: adding support for Davinci AIS image · 4962e38e
      Stefano Babic authored
      
      Some Davinci processors supports the Application
      Image Script (AIS) boot process. The patch adds the generation
      of the AIS image inside the mkimage tool to make possible
      to generate a bootable U-boot without external tools
      (TI Davinci AIS Generator).
      
      Signed-off-by: default avatarStefano Babic <sbabic@denx.de>
      CC: Wolfgang Denk <wd@denx.de>
      4962e38e
  21. Oct 21, 2011
    • Stephen Warren's avatar
      checkpatch whitespace cleanups · 712fbcf3
      Stephen Warren authored
      
      This avoids the following checkpatch warning in later patches:
      
      ERROR: "(foo*)" should be "(foo *)"
      ERROR: space required before the open brace '{'
      ERROR: space prohibited before that close parenthesis ')'
      ERROR: spaces required around that '||' (ctx:WxV)
      WARNING: space prohibited between function name and open parenthesis '('
      WARNING: line over 80 characters
      
      This fixes all the white-space warnings/errors in my subsequent patch,
      and within this current patch. A number of other checkpatch warnings
      and errors are still present in this patch itself, but are beyond simple
      whitespace fixes, so are not solved by this patch.
      
      v2: New patch
      
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      Tested-by: default avatarSimon Glass <sjg@chromium.org>
      Tested-by: default avatarSimon Glass <sjg@chromium.org>
      712fbcf3
    • Macpaul Lin's avatar
      nds32: common bdinfo, bootm, image support · 64d61461
      Macpaul Lin authored
      
      Add support of NDS32 to common commands bdinfo, bootm, and image format.
      
      Signed-off-by: default avatarMacpaul Lin <macpaul@andestech.com>
      64d61461
  22. Oct 17, 2011
  23. Oct 09, 2011
  24. Sep 07, 2011
  25. Aug 03, 2011
Loading