1. 08 Mar, 2016 1 commit
  2. 08 Feb, 2016 1 commit
    • Stephen Warren's avatar
      malloc: solve dead code issue in memalign() · ee05fedc
      Stephen Warren authored
      The recent change to memalign() caused the allocation failure detection
      code to be dead code; the "retry" logic is always activated under the same
      condition that the original failure detection code is, and also fully
      handles any possible failures. This patch solves the presence of dead
      code.
      
      Two alternatives are possible:
      
      a) Delete the now-dead test, and rely on the "retry" path to handle any
      allocation problems, as it does.
      
      b) Make the "retry" path fall through to the existing (currently dead)
      failure detection code, thus making it not-dead.
      
      (b) was chosen since it reduces the diff between U-Boot's and the upstream
      dlmalloc. This should make it marginally easier to import a new version of
      dlmalloc in the future.
      
      Reported by: Coverity Scan
      Fixes: 4f144a41 ("malloc: work around some memalign fragmentation issues")
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      Reviewed-by: default avatarTom Rini <trini@konsulko.com>
      ee05fedc
  3. 01 Feb, 2016 1 commit
    • Stephen Warren's avatar
      malloc: work around some memalign fragmentation issues · 4f144a41
      Stephen Warren authored
      Use of memalign can trigger fragmentation issues such as:
      
      // Internally, this needs to find a free block quite bit larger than s.
      // Once the free region is found, any unaligned "padding" immediately
      // before and after the block is marked free, so that the allocation
      // takes only s bytes (plus malloc header overhead).
      p = memalign(a, s);
      // If there's little fragmentation so far, this allocation is likely
      // located immediately after p.
      p2 = malloc(x);
      free(p);
      // In theory, this should return the same value for p. However, the hole
      // left by the free() call is only s in size (plus malloc header overhead)
      // whereas memalign searches for a larger block in order to guarantee it
      // can adjust the returned pointer to the alignment requirements. Hence,
      // the pointer returned, if any, won't be p. If there's little or no space
      // left after p2, this allocation will fail.
      p = memalign(a, s);
      
      In practice, this issue occurs when running the "dfu" command repeatedly
      on NVIDIA Tegra boards, since DFU allocates a large 32M data buffer, and
      then initializes the USB controller. If this is the first time USB has
      been used in the U-Boot session, this causes a probe of the USB driver,
      which causes various allocations, including a strdup() of a GPIO name
      when requesting the VBUS GPIO. When DFU is torn down, the USB driver
      is left probed, and hence its memory is left allocated. If "dfu" is
      executed again, allocation of the 32M data buffer fails as described
      above.
      
      In practice, there is a memory hole exactly large enough to hold the 32M
      data buffer than DFU needs. However, memalign() can't know that in a
      general way. Given that, it's particularly annoying that the allocation
      fails!
      
      The issue is that memalign() tries to allocate something larger to
      guarantee the ability to align the returned pointer. This patch modifies
      memalign() so that if the "general case" over-sized allocation fails,
      another allocation is attempted, of the exact size the user desired. If
      that allocation just happens to be aligned in the way the user wants,
      (and in the case described above, it will be, since the free memory
      region is located where a previous identical allocation was located),
      the pointer can be returned.
      
      This patch is somewhat related to 806bd245 "dfu: don't keep
      freeing/reallocating". That patch worked around the issue by removing
      repeated free/memalign within a single execution of "dfu". However,
      the same technique can't be applied across multiple invocations, since
      there's no reason to keep the DFU buffer allocated while DFU isn't
      running. This patch addresses the root-cause a bit more directly.
      
      This problem highlights some of the disadvantages of dynamic allocation
      and deferred probing of devices.
      
      This patch isn't checkpatch-clean, since it conforms to the existing
      coding style in dlmalloc.c, which is different to the rest of U-Boot.
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      Reviewed-by: default avatarTom Rini <trini@konsulko.com>
      Acked-by: default avatarLukasz Majewski <l.majewski@samsung.com>
      4f144a41
  4. 23 Apr, 2015 1 commit
  5. 09 Mar, 2015 1 commit
    • Przemyslaw Marczak's avatar
      dlmalloc: do memset in malloc init as new default config · 0aa8a4ad
      Przemyslaw Marczak authored
      This commit introduces new config: CONFIG_SYS_MALLOC_CLEAR_ON_INIT.
      
      This config is an expert option and is enabled by default.
      
      The all amount of memory reserved for the malloc, is by default set
      to zero in mem_malloc_init(). When the malloc reserved memory exceeds
      few MiB, then the boot process can slow down.
      
      So disabling this config, is an expert option to reduce the boot time,
      and can be disabled by Kconfig.
      
      Note:
      After disable this option, only calloc() will return the pointer
      to the zeroed memory area. Previously, without this option,
      the memory pointed to untouched malloc memory region, was filled
      with zeros. So it means, that code with malloc() calls should
      be reexamined.
      Signed-off-by: default avatarPrzemyslaw Marczak <p.marczak@samsung.com>
      Reviewed-by: default avatarSimon Glass <sjg@chromium.org>
      0aa8a4ad
  6. 21 Nov, 2014 1 commit
    • Simon Glass's avatar
      dm: Split the simple malloc() implementation into its own file · c9356be3
      Simon Glass authored
      The simple malloc() implementation is used when memory is tight. It provides
      a simple buffer with an incrementing pointer.
      
      At present the implementation is inside dlmalloc. Move it into its own file
      so that it is easier to find.
      
      Rather than using relocation as a signal that the full malloc() is
      available, add a special GD_FLG_FULL_MALLOC_INIT flag. This signals that the
      simple malloc() should no longer be used.
      
      In some cases, such as SPL, even the code space used by the full malloc() is
      wasteful. Add a CONFIG_SYS_MALLOC_SIMPLE option to provide only the simple
      malloc. In this case the full malloc is not available at all. It saves about
      1KB of code space and about 0.5KB of data on Thumb 2.
      Acked-by: default avatarTom Rini <trini@ti.com>
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
      c9356be3
  7. 12 Nov, 2014 1 commit
  8. 07 Nov, 2014 1 commit
    • Rabin Vincent's avatar
      dlmalloc: ensure gd is set for early alloc · 854d2b97
      Rabin Vincent authored
      Attempting to run the sandbox leads to a segfault, because some dynamic
      libraries (outside of u-boot) attempt to use malloc() to allocate memory
      before u-boot's gd variable is initialized.
      
      Check for gd not being NULL in the SYS_MALLOC_F_LEN handling, so that
      malloc() doesn't crash when called at this point.
      
       $ gdb -q --args ./u-boot
       (gdb) r
       Program received signal SIGSEGV, Segmentation fault.
       0x0000000000412b9b in malloc (bytes=bytes@entry=37) at common/dlmalloc.c:2184
       2184		if (!(gd->flags & GD_FLG_RELOC)) {
       (gdb) p gd
       $1 = (gd_t *) 0x0
       (gdb) bt
       #0  0x0000000000412b9b in malloc (bytes=bytes@entry=37) at common/dlmalloc.c:2184
       #1  0x00007ffff75bf8e1 in set_binding_values (domainname=0x7ffff11f4f12 "libgpg-error", dirnamep=0x7fffffffe168, codesetp=0x0)
           at bindtextdom.c:228
       #2  0x00007ffff75bfb4c in set_binding_values (codesetp=0x0, dirnamep=0x7fffffffe168, domainname=<optimized out>) at bindtextdom.c:350
       #3  __bindtextdomain (domainname=<optimized out>, dirname=0x7ffff11f4f00 "/usr/share/locale") at bindtextdom.c:348
       #4  0x00007ffff11eca17 in ?? () from /lib/x86_64-linux-gnu/libgpg-error.so.0
       #5  0x00007ffff7dea9fa in call_init (l=<optimized out>, argc=argc@entry=1, argv=argv@entry=0x7fffffffe208,
           env=env@entry=0x7fffffffe218) at dl-init.c:78
       #6  0x00007ffff7deaae3 in call_init (env=0x7fffffffe218, argv=0x7fffffffe208, argc=1, l=<optimized out>) at dl-init.c:36
       #7  _dl_init (main_map=0x7ffff7ffe1a8, argc=1, argv=0x7fffffffe208, env=0x7fffffffe218) at dl-init.c:126
       #8  0x00007ffff7ddd1ca in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
      Signed-off-by: default avatarRabin Vincent <rabin@rab.in>
      Acked-by: default avatarSimon Glass <sjg@chromium.org>
      854d2b97
  9. 23 Jul, 2014 3 commits
    • Simon Glass's avatar
      sandbox: Always enable malloc debug · 6d7601e7
      Simon Glass authored
      Tun on DEBUG in malloc(). This adds code space and slows things down but
      for sandbox this is acceptable. We gain the ability to check for memory
      leaks in tests.
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
      6d7601e7
    • Simon Glass's avatar
      Add a simple malloc() implementation for pre-relocation · d59476b6
      Simon Glass authored
      If we are to have driver model before relocation we need to support some
      way of calling memory allocation routines.
      
      The standard malloc() is pretty complicated:
      
      1. It uses some BSS memory for its state, and BSS is not available before
      relocation
      
      2. It supports algorithms for reducing memory fragmentation and improving
      performace of free(). Before relocation we could happily just not support
      free().
      
      3. It includes about 4KB of code (Thumb 2) and 1KB of data. However since
      this has been loaded anyway this is not really a problem.
      
      The simplest way to support pre-relocation malloc() is to reserve an area
      of memory and allocate it in increasing blocks as needed. This
      implementation does this.
      
      To enable it, you need to define the size of the malloc() pool as described
      in the README. It will be located above the pre-relocation stack on
      supported architectures.
      
      Note that this implementation is only useful on machines which have some
      memory available before dram_init() is called - this includes those that
      do no DRAM init (like tegra) and those that do it in SPL (quite a few
      boards). Enabling driver model preior to relocation for the rest of the
      boards is left for a later exercise.
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
      d59476b6
    • Simon Glass's avatar
      Remove form-feeds from dlmalloc.c · d93041a4
      Simon Glass authored
      These don't really serve any purpose in the modern age. On the other hand
      they show up as annoying control characters in my editor, which then happily
      removes them.
      
      I believe we can drop these characters from the file.
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
      d93041a4
  10. 01 Apr, 2013 1 commit
    • York Sun's avatar
      Consolidate bool type · 472d5460
      York Sun authored
      'bool' is defined in random places. This patch consolidates them into a
      single header file include/linux/types.h, using stdbool.h introduced in C99.
      
      All other #define, typedef and enum are removed. They are all consistent with
      true = 1, false = 0.
      
      Replace FALSE, False with false. Replace TRUE, True with true.
      Skip *.py, *.php, lib/* files.
      Signed-off-by: default avatarYork Sun <yorksun@freescale.com>
      472d5460
  11. 19 Feb, 2013 1 commit
    • Gabor Juhos's avatar
      malloc: make malloc_bin_reloc static · 7b395232
      Gabor Juhos authored
      On architectures where manual relocation
      is needed, the 'malloc_bin_reloc' function
      must be called after 'mem_malloc_init'.
      
      Make the 'malloc_bin_reloc' function static
      and call it directly from 'mem_malloc_init'
      instead of calling that from board_init_{r,f}
      functions of the affected architectures.
      Signed-off-by: default avatarGabor Juhos <juhosg@openwrt.org>
      Cc: Wolfgang Denk <wd@denx.de>
      Cc: Andreas Bießmann <andreas.devel@gmail.com>
      Cc: Jason Jin <Jason.jin@freescale.com>
      Cc: Macpaul Lin <macpaul@andestech.com>
      Cc: Daniel Hellstrom <daniel@gaisler.com>
      Cc: Daniel Schwierzeck <daniel.schwierzeck@googlemail.com>
      7b395232
  12. 04 Nov, 2012 1 commit
    • 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
  13. 13 Sep, 2012 1 commit
    • Simon Glass's avatar
      Fix strict-aliasing warning in dlmalloc · 93691842
      Simon Glass authored
      This fixes the following warnings in dlmalloc seen with my gcc 4.6.
      
      dlmalloc.c: In function 'malloc_bin_reloc':
      dlmalloc.c:1493: warning: dereferencing pointer 'p' does break strict-aliasing rules
      dlmalloc.c:1493: warning: dereferencing pointer 'p' does break strict-aliasing rules
      dlmalloc.c:1490: note: initialized from here
      dlmalloc.c:1493: note: initialized from here
      
      This version is tested on avr32 arch boards.
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
      Signed-off-by: default avatarAndreas Bießmann <andreas.devel@googlemail.com>
      93691842
  14. 10 Sep, 2011 1 commit
    • Wolfgang Denk's avatar
      utx8245: fix build breakage due to assert() · ea95cb73
      Wolfgang Denk authored
      Commit 21726a7a "Add assert() for debug assertions" broke building the
      utx8245 board:
      
      dlmalloc.c: In function 'do_check_chunk':
      dlmalloc.c:1660: error: 'sz' undeclared (first use in this function)
      dlmalloc.c:1660: error: (Each undeclared identifier is reported only once
      dlmalloc.c:1660: error: for each function it appears in.)
      dlmalloc.c: In function 'do_check_free_chunk':
      dlmalloc.c:1689: error: 'next' undeclared (first use in this function)
      dlmalloc.c: In function 'do_check_malloced_chunk':
      dlmalloc.c:1748: error: 'sz' undeclared (first use in this function)
      dlmalloc.c:1750: error: 'room' undeclared (first use in this function)
      Signed-off-by: default avatarWolfgang Denk <wd@denx.de>
      Cc: Simon Glass <sjg@chromium.org>
      ea95cb73
  15. 09 Sep, 2011 1 commit
    • Simon Glass's avatar
      Add assert() for debug assertions · 21726a7a
      Simon Glass authored
      assert() is like BUG_ON() but compiles to nothing unless DEBUG is defined.
      This is useful when a condition is an error but a board reset is unlikely
      to fix it, so it is better to soldier on in hope. Assertion failures should
      be caught during development/test.
      
      It turns out that assert() is defined separately in a few places in U-Boot
      with various meanings. This patch cleans up some of these.
      
      Build errors exposed by this change (and defining DEBUG) are also fixed in
      this patch.
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
      21726a7a
  16. 17 Nov, 2010 1 commit
    • Kumar Gala's avatar
      malloc: Fix issue with calloc memory possibly being non-zero · 6163f5b4
      Kumar Gala authored
      Since we set #define MORECORE_CLEARS 1, the code assumes 'sbrk' always
      returns zero'd out memory.  However since its possible that free()
      returns memory back to sbrk() via malloc_trim we could possible get
      non-zero'd memory from sbrk().  This is a problem for when code might
      call calloc() and expect the memory to have been zero'd out.
      
      There are two possible solutions to this problem.
      1. change #define MORECORE_CLEARS 0
      2. memset to zero memory returned to sbrk.
      
      We go with the second since the sbrk being called to free up memory
      should be pretty rare.
      
      The following code problems an example test to show the issue.  This
      test code was inserted right after the call to mem_malloc_init().
      
      ...
             u8 *p2;
             int i;
      
             printf("MALLOC TEST\n");
             p1 = malloc(135176);
             printf("P1 = %p\n", p1);
             memset(p1, 0xab, 135176);
      
             free(p1);
             p2 = calloc(4097, 1);
             printf("P2 = %p %p\n", p2, p2 + 4097);
      
             for (i = 0; i < 4097; i++) {
      	       if (p2[i] != 0)
      		       printf("miscompare at byte %d got %x\n", i, p2[i]);
      
             free(p2);
             printf("END MALLOC TEST\n\n");
      ...
      Signed-off-by: default avatarKumar Gala <galak@kernel.crashing.org>
      Tested-by: default avatarWolfgang Denk <wd@denx.de>
      6163f5b4
  17. 29 Oct, 2010 1 commit
  18. 18 Oct, 2010 1 commit
  19. 19 Sep, 2010 1 commit
    • Wolfgang Denk's avatar
      New implementation for internal handling of environment variables. · ea882baf
      Wolfgang Denk authored
      Motivation:
      
      * Old environment code used a pessimizing implementation:
        - variable lookup used linear search => slow
        - changed/added variables were added at the end, i. e. most
          frequently used variables had the slowest access times => slow
        - each setenv() would calculate the CRC32 checksum over the whole
          environment block => slow
      * "redundant" envrionment was locked down to two copies
      * No easy way to implement features like "reset to factory defaults",
        or to select one out of several pre-defined (previously saved) sets
        of environment settings ("profiles")
      * No easy way to import or export environment settings
      
      ======================================================================
      
      API Changes:
      
      - Variable names starting with '#' are no longer allowed
      
        I didn't find any such variable names being used; it is highly
        recommended to follow standard conventions and start variable names
        with an alphanumeric character
      
      - "printenv" will now print a backslash at the end of all but the last
        lines of a multi-line variable value.
      
        Multi-line variables have never been formally defined, allthough
        there is no reason not to use them. Now we define rules how to deal
        with them, allowing for import and export.
      
      - Function forceenv() and the related code in saveenv() was removed.
        At the moment this is causing build problems for the only user of
        this code (schmoogie - which has no entry in MAINTAINERS); may be
        fixed later by implementing the "env set -f" feature.
      
      Inconsistencies:
      
      - "printenv" will '\\'-escape the '\n' in multi-line variables, while
        "printenv var" will not do that.
      
      ======================================================================
      
      Advantages:
      
      - "printenv" output much better readable (sorted)
      - faster!
      - extendable (additional variable properties can be added)
      - new, powerful features like "factory reset" or easy switching
        between several different environment settings ("profiles")
      
      Disadvantages:
      
      - Image size grows by typically 5...7 KiB (might shrink a bit again on
        systems with redundant environment with a following patch series)
      
      ======================================================================
      
      Implemented:
      
      - env command with subcommands:
      
        - env print [arg ...]
      
          same as "printenv": print environment
      
        - env set [-f] name [arg ...]
      
          same as "setenv": set (and delete) environment variables
      
          ["-f" - force setting even for read-only variables - not
          implemented yet.]
      
        - end delete [-f] name
      
          not implemented yet
      
          ["-f" - force delete even for read-only variables]
      
        - env save
      
          same as "saveenv": save environment
      
        - env export [-t | -b | -c] addr [size]
      
          export internal representation (hash table) in formats usable for
          persistent storage or processing:
      
      	-t:	export as text format; if size is given, data will be
      		padded with '\0' bytes; if not, one terminating '\0'
      		will be added (which is included in the "filesize"
      		setting so you can for exmple copy this to flash and
      		keep the termination).
      	-b:	export as binary format (name=value pairs separated by
      		'\0', list end marked by double "\0\0")
      	-c:	export as checksum protected environment format as
      		used for example by "saveenv" command
      	addr:	memory address where environment gets stored
      	size:	size of output buffer
      
      	With "-c" and size is NOT given, then the export command will
      	format the data as currently used for the persistent storage,
      	i. e. it will use CONFIG_ENV_SECT_SIZE as output block size and
      	prepend a valid CRC32 checksum and, in case of resundant
      	environment, a "current" redundancy flag. If size is given, this
      	value will be used instead of CONFIG_ENV_SECT_SIZE; again, CRC32
      	checksum and redundancy flag will be inserted.
      
      	With "-b" and "-t", always only the real data (including a
      	terminating '\0' byte) will be written; here the optional size
      	argument will be used to make sure not to overflow the user
      	provided buffer; the command will abort if the size is not
      	sufficient. Any remainign space will be '\0' padded.
      
              On successful return, the variable "filesize" will be set.
              Note that filesize includes the trailing/terminating '\0'
              byte(s).
      
              Usage szenario: create a text snapshot/backup of the current
      	settings:
      
      		=> env export -t 100000
      		=> era ${backup_addr} +${filesize}
      		=> cp.b 100000 ${backup_addr} ${filesize}
      
      	Re-import this snapshot, deleting all other settings:
      
      		=> env import -d -t ${backup_addr}
      
        - env import [-d] [-t | -b | -c] addr [size]
      
          import external format (text or binary) into hash table,
          optionally deleting existing values:
      
      	-d:	delete existing environment before importing;
      		otherwise overwrite / append to existion definitions
      	-t:	assume text format; either "size" must be given or the
      		text data must be '\0' terminated
      	-b:	assume binary format ('\0' separated, "\0\0" terminated)
      	-c:	assume checksum protected environment format
      	addr:	memory address to read from
      	size:	length of input data; if missing, proper '\0'
      		termination is mandatory
      
        - env default -f
      
          reset default environment: drop all environment settings and load
          default environment
      
        - env ask name [message] [size]
      
          same as "askenv": ask for environment variable
      
        - env edit name
      
          same as "editenv": edit environment variable
      
        - env run
      
          same as "run": run commands in an environment variable
      
      ======================================================================
      
      TODO:
      
      - drop default env as implemented now; provide a text file based
        initialization instead (eventually using several text files to
        incrementally build it from common blocks) and a tool to convert it
        into a binary blob / object file.
      
      - It would be nice if we could add wildcard support for environment
        variables; this is needed for variable name auto-completion,
        but it would also be nice to be able to say "printenv ip*" or
        "printenv *addr*"
      
      - Some boards don't link any more due to the grown code size:
        DU405, canyonlands, sequoia, socrates.
      
      	=> cc: Matthias Fuchs <matthias.fuchs@esd-electronics.com>,
      	       Stefan Roese <sr@denx.de>,
      	       Heiko Schocher <hs@denx.de>
      
      - Dropping forceenv() causes build problems on schmoogie
      
      	=> cc: Sergey Kubushyn <ksi@koi8.net>
      
      - Build tested on PPC and ARM only; runtime tested with NOR and NAND
        flash only => needs testing!!
      Signed-off-by: default avatarWolfgang Denk <wd@denx.de>
      Cc: Matthias Fuchs <matthias.fuchs@esd-electronics.com>,
      Cc: Stefan Roese <sr@denx.de>,
      Cc: Heiko Schocher <hs@denx.de>
      Cc: Sergey Kubushyn <ksi@koi8.net>
      ea882baf
  20. 09 Apr, 2010 1 commit
  21. 15 Jan, 2010 1 commit
    • Wolfgang Denk's avatar
      malloc: return NULL if not initialized yet · 27405448
      Wolfgang Denk authored
      When malloc() was called before it was properly initialized
      (as would happen if when used before relocation to RAM) it returned
      random, non-NULL values, which called all kinds of difficult to debug
      subsequent errors.
      
      Make sure to return NULL when initialization was not done yet.
      Signed-off-by: default avatarWolfgang Denk <wd@denx.de>
      27405448
  22. 05 Dec, 2009 1 commit
  23. 03 Oct, 2009 3 commits
  24. 04 Sep, 2009 2 commits
  25. 06 Aug, 2008 1 commit
  26. 31 Jul, 2008 1 commit
    • Kumar Gala's avatar
      Fix compile warnings in dlmalloc · 57c219ad
      Kumar Gala authored
      The origional code was using on odd reference to get to the first
      real element in av_[].  The first two elements of the array are
      not used for actual bins, but for house keeping.  If we are more
      explicit about how use the first few elements we can get rid of the
      warnings:
      
      dlmalloc.c: In function 'malloc_extend_top':
      dlmalloc.c:1971: warning: dereferencing type-punned pointer will break strict-aliasing rules
      dlmalloc.c:1999: warning: dereferencing type-punned pointer will break strict-aliasing rules
      dlmalloc.c:2029: warning: dereferencing type-punned pointer will break strict-aliasing rules
      ...
      
      The logic of how this code came to be is:
      	bin_at(0) = (char*)&(av_[2]) - 2*SIZE_SZ
      
      SIZE_SZ is the size of pointer, and av_ is arry of pointers so:
      	bin_at(0) = &(av_[0])
      
      Going from there to bin_at(0)->fd or bin_at(0)->size should be straight forward.
      Signed-off-by: default avatarKumar Gala <galak@kernel.crashing.org>
      57c219ad
  27. 03 Jun, 2008 1 commit
  28. 31 Mar, 2006 1 commit
  29. 27 Jun, 2003 1 commit
    • wdenk's avatar
      * Code cleanup: · 8bde7f77
      wdenk authored
        - remove trailing white space, trailing empty lines, C++ comments, etc.
        - split cmd_boot.c (separate cmd_bdinfo.c and cmd_load.c)
      
      * Patches by Kenneth Johansson, 25 Jun 2003:
        - major rework of command structure
          (work done mostly by Michal Cendrowski and Joakim Kristiansen)
      8bde7f77
  30. 25 Oct, 2002 1 commit
  31. 19 Jul, 2000 1 commit